You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Ayhan Kondoz <Ay...@freenet-ag.de> on 2007/02/21 09:55:52 UTC

possible bug / memory leak in DispatchQueue and EventManager?

Hi,

 

i think i found a possible bug / memory leak within the DispatchQueue and EventManager.

 

 

First a little bit about my setup:

 

I have 3 servers. Each server runs an axis service. The service uses cayenne 1.2.1 to connect to a database. It reads customer and account information from the DB etc..

The servers are using cayenne's shared caching with javagroups as the messaging service so that changes made from one server are dispatched to the other servers.

 

The avarage connections per second is somewhere around 4-5.

 

However I have a very strange problem with this setup so I startet to search for the reason. The problem is that with nearly constant and unchanging usage the load of each server increases over time. To further test this I created a test server with a similar setup. There I created a test program that creates totally constant usage. But even with the unchanging usage the load of the server is increasing until the cpu load is so high that the requests can not be processed anymore.

 

I installed a java profiler to trying to pinpoint the location of this error and this is what I found out.

 

I let the server run for 24 hours and then stopped the program which creates the test usage.

But even while the server was idle there where still a lot of instances in the java heap after the GC run.

 

http://img206.imageshack.us/img206/9769/memorysy5.jpg

 

Please note the HashMap, WeakReference and Invocation counts. I pressume that the $ObjectProvider_*** is cayenne aswell but I am not sure.

 

Now the following image shows the cpu profile with incoming connections.

 

http://img339.imageshack.us/img339/2441/cpuci0.jpg

 

As you can see 58% of the cpu time is used within HashSet.add().

 

So when I consider the two facts i think that there might be a possible problem with the EventManager. The first table tells us that there are over 1 million instances of HashSet's and cayenne Invocations. So it seems like the set's within the DispatchQueue are not recycled properly so that the object count rises over time which result in extremly high processtime when trying to add new HashSet's.

 

 

Thanks

Ayhan

 

 

 

Ayhan Kondoz

 

Software-Entwicklung

 

----------------------------------------------------------------------------------

Telefon:    +49 (0) 40 513 06 616

Telefax:    +49 (0) 40 513 06 998 616

E-Mail:     ayhan.kondoz@freenet-ag.de <ma...@freenet-ag.de> 

Website:  http://www.freenet.de <http://www.freenet.de/> ; http://www.freenet-ag.de <http://www.freenet-ag.de/> 

----------------------------------------------------------------------------------

freenet.de AG

Deelbögenkamp 4c

22297 Hamburg

----------------------------------------------------------------------------------

Vorsitzender des Aufsichtsrates: Prof. Dr. Helmut Thoma

Vorstand: Eckhard Spoerr (Vors.), 
Axel Krieger, Stephan Esch, Eric Berger

Amtsgericht Hamburg HRB 74048

 

 

Diese Information ist ausschließlich für die adressierte Person oder Organisation bestimmt und könnte vertrauliches und/oder privilegiertes Material enthalten. Personen oder Organisationen, für die diese Information nicht bestimmt ist, ist es nicht gestattet, diese zu lesen, erneut zu übertragen, zu verbreiten, anderweitig zu verwenden oder sich durch sie veranlasst zu sehen, Maßnahmen irgendeiner Art zu ergreifen. Sollten Sie diese Nachricht irrtümlich erhalten haben, bitten wir Sie, sich mit dem Absender in Verbindung zu setzen und das Material von Ihrem Computer zu löschen. 

 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

 


Re: possible bug / memory leak in DispatchQueue and EventManager?

Posted by Andrus Adamchik <an...@objectstyle.org>.
Seems like your assessment of the EventManager leaking is correct.

Now the cause is not that clear. A shot in the dark - this is due to  
a combination of lots of spare memory in JVM (so weak references are  
not collected fast enough) and slow custom 'equals' and 'hashCode'  
methods in invocation.

How much heap size do you have in your server? Also can you try to  
add a request filter that would do 'System.gc()' on every few  
thousands requests, and see if it makes any difference.

Also - do you see any EventManager exceptions in the logs?

Andrus


On Feb 21, 2007, at 10:55 AM, Ayhan Kondoz wrote:
> Hi,
>
>
>
> i think i found a possible bug / memory leak within the  
> DispatchQueue and EventManager.
>
>
>
>
>
> First a little bit about my setup:
>
>
>
> I have 3 servers. Each server runs an axis service. The service  
> uses cayenne 1.2.1 to connect to a database. It reads customer and  
> account information from the DB etc..
>
> The servers are using cayenne's shared caching with javagroups as  
> the messaging service so that changes made from one server are  
> dispatched to the other servers.
>
>
>
> The avarage connections per second is somewhere around 4-5.
>
>
>
> However I have a very strange problem with this setup so I startet  
> to search for the reason. The problem is that with nearly constant  
> and unchanging usage the load of each server increases over time.  
> To further test this I created a test server with a similar setup.  
> There I created a test program that creates totally constant usage.  
> But even with the unchanging usage the load of the server is  
> increasing until the cpu load is so high that the requests can not  
> be processed anymore.
>
>
>
> I installed a java profiler to trying to pinpoint the location of  
> this error and this is what I found out.
>
>
>
> I let the server run for 24 hours and then stopped the program  
> which creates the test usage.
>
> But even while the server was idle there where still a lot of  
> instances in the java heap after the GC run.
>
>
>
> http://img206.imageshack.us/img206/9769/memorysy5.jpg
>
>
>
> Please note the HashMap, WeakReference and Invocation counts. I  
> pressume that the $ObjectProvider_*** is cayenne aswell but I am  
> not sure.
>
>
>
> Now the following image shows the cpu profile with incoming  
> connections.
>
>
>
> http://img339.imageshack.us/img339/2441/cpuci0.jpg
>
>
>
> As you can see 58% of the cpu time is used within HashSet.add().
>
>
>
> So when I consider the two facts i think that there might be a  
> possible problem with the EventManager. The first table tells us  
> that there are over 1 million instances of HashSet's and cayenne  
> Invocations. So it seems like the set's within the DispatchQueue  
> are not recycled properly so that the object count rises over time  
> which result in extremly high processtime when trying to add new  
> HashSet's.
>
>
>
>
>
> Thanks
>
> Ayhan
>
>
>
>
>
>
>
> Ayhan Kondoz
>
>
>
> Software-Entwicklung
>
>
>
> ---------------------------------------------------------------------- 
> ------------
>
> Telefon:    +49 (0) 40 513 06 616
>
> Telefax:    +49 (0) 40 513 06 998 616
>
> E-Mail:     ayhan.kondoz@freenet-ag.de <mailto:ayhan.kondoz@freenet- 
> ag.de>
>
> Website:  http://www.freenet.de <http://www.freenet.de/> ; http:// 
> www.freenet-ag.de <http://www.freenet-ag.de/>
>
> ---------------------------------------------------------------------- 
> ------------
>
> freenet.de AG
>
> Deelbögenkamp 4c
>
> 22297 Hamburg
>
> ---------------------------------------------------------------------- 
> ------------
>
> Vorsitzender des Aufsichtsrates: Prof. Dr. Helmut Thoma
>
> Vorstand: Eckhard Spoerr (Vors.),
> Axel Krieger, Stephan Esch, Eric Berger
>
> Amtsgericht Hamburg HRB 74048
>
>
>
>
>
> Diese Information ist ausschließlich für die adressierte Person  
> oder Organisation bestimmt und könnte vertrauliches und/oder  
> privilegiertes Material enthalten. Personen oder Organisationen,  
> für die diese Information nicht bestimmt ist, ist es nicht  
> gestattet, diese zu lesen, erneut zu übertragen, zu verbreiten,  
> anderweitig zu verwenden oder sich durch sie veranlasst zu sehen,  
> Maßnahmen irgendeiner Art zu ergreifen. Sollten Sie diese Nachricht  
> irrtümlich erhalten haben, bitten wir Sie, sich mit dem Absender in  
> Verbindung zu setzen und das Material von Ihrem Computer zu löschen.
>
>
>
> The information transmitted is intended only for the person or  
> entity to which it is addressed and may contain confidential and/or  
> privileged material. Any review, retransmission, dissemination or  
> other use of, or taking of any action in reliance upon, this  
> information by persons or entities other than the intended  
> recipient is prohibited. If you received this in error, please  
> contact the sender and delete the material from any computer.
>
>
>


RE: To severe things

Posted by Chris Farnham <cf...@cra.com>.
Jan,

You may have already fixed your problem (1) detailed below but I thought
you may like to know that I had the exact same problem and I was able to
fix it.

I added 'deleteRule="Nullify"' to my 'Evidence->User' relationship which
seems very much like your Notiz->Person relationship.

	<obj-relationship name="user" source="EvidenceDAO"
deleteRule="Nullify"
		target="UserDAO" db-relationship-path="evidence_to_user"
/>

This change to the xml mapping file (which I maintain by hand) fixed the
NullPointerException I was receiving.

Christopher Farnham
Senior Software Engineer
Decision Management Division
cfarnham@cra.com
617.491.3474 x562

Charles River Analytics
625 Mount Auburn Street
Cambridge, MA 02138
http://www.cra.com
> 
 
 
 
 
THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records.
 
-----Original Message-----
 
 

> From: Jan Lendholt [mailto:jlendholt@hotmail.com]
> Sent: Friday, September 14, 2007 7:59 AM
> To: user@cayenne.apache.org
> Subject: Re: To severe things
> 
> Hi Kevin,
> 
> To (1):
> 
> two snippets I can give you. Unfortunately we do not have a fitting
test
> case.
> 
> The "faulty" object is stored in a list and the delete via
> context.deleteObject:
> 
> //Thios expression fetches all persons that should be deleted from a
note
> Expression delExp =
> ExpressionFactory.matchExp(Mappingnotizperson.TO_NOTIZ_PROPERTY,
>
notiz.getObjectId()).andExp(ExpressionFactory.matchExp(Mappingnotizperso
n.
> TO_PERSONEN_PROPERTY,
> each.getObjectId()));
> 
> 						SelectQuery selQ = new
> SelectQuery(Mappingnotizperson.class,delExp);
> 
> //perform the query
> List<Mappingnotizperson> m = this.context.performQuery(selQ);
> //Delete the object
> this.context.deleteObject(m.get(0));
> this.context.commitChanges();
> 
> Now the corresponding object is marked as transient and is deleted.
> 
> //This refetches all persons that are assigned to one note.
> List<Mappingnotizperson> mapList =
> this.notiz.getMappingnotizpersonArray();
> 			System.err.println("notizid:"+
notizShow.getObjectId());
> 			for (Mappingnotizperson mappingnotizperson :
mapList) {
> 				System.err.println("mapp: pers-state:" +
> mappingnotizperson.getPersistenceState()); // + " --- persid:" +
> mappingnotizperson.getToPersonen());
> 
> 	this.persList.add(mappingnotizperson.getToPersonen()); //**
> 
> 	this.existPers.add(mappingnotizperson.getToPersonen());
> 			}
> 
> ** Here we get the NullPointerException that tells us, that the person
of
> this mapping is null.
> 
> Hope you can start with what we've got.
> 
> To (2):
> 
> We're using cayenne 2.0.3 with a customized db adapter to be used with
max
> db.
> 
> To me, the method prepareForAccess makes no sense.
> At first it's checked againstz being hollow and afterwards it's
checked
> against being commited - but how should it be commited when it's
already
> hollow??
> 
> Thanks in advance guys.
> 
> Jan
> 
> 
> 
> >From: Kevin Menard <km...@servprise.com>
> >Reply-To: user@cayenne.apache.org
> >To: <us...@cayenne.apache.org>
> >Subject: Re: To severe things
> >Date: Thu, 13 Sep 2007 15:21:52 -0400
> >
> >Hi Jan,
> >
> >I'm snipping out a lot of just to get to a few basic questions I
have.
> >
> >
> >On 9/13/07 1:25 PM, "Jan Lendholt" <jl...@hotmail.com> wrote:
> >
> > > Well, this exception comes on an object with the PersistenceState
=
> > > Transient. The exception is thrown when in doResolveFault cayenne
> tries
> >to
> > > access the object's context.
> > > But why? This object shouldn't even be there! In my opinion this
is a
> >bug.
> > > It doesn't matter, if we delete the object with deletObject or
with a
> >delet
> > > query. How can it be? It's pretty severe though.
> >
> >If possible, could you please post the code that seems to trigger the
> >error?
> >A small test case would be perfect, but showing anything would be
> helpful.
> >
> > > (2)
> > > I try to access a mapping table again, this time we manage
resources
> >like
> > > rooms, beamers etc.
> > >
> > > I get all mappings and try to access via
> >mapping.getToResource().getname()
> > > the resource's name.
> > >
> > > We get:
> > >
> > > 19:22:49.168 WARN!! Exception for /ams?serviceId=Echo.Synchronize
> > > org.apache.cayenne.FaultFailureException: [v.@CAYENNE_VERSION@
> > > @CAYENNE_BUILD_DATE@] Error resolving fault for ObjectId:
> > > <ObjectId:Resource, IDRESOURCE=1> and state (hollow). Possible
cause -
> > > matching row is missing from the database.
> >
> >What version of Cayenne are you actually using?
> >
> >--
> >Kevin
> >
> 
> _________________________________________________________________
> Haben Spinnen Ohren? Finden Sie es heraus - mit dem MSN Suche
Superquiz
> via
> http://www.msn-superquiz.de  Jetzt mitmachen und gewinnen!

Re: To severe things

Posted by Jan Lendholt <jl...@hotmail.com>.
Hi Kevin,

To (1):

two snippets I can give you. Unfortunately we do not have a fitting test 
case.

The "faulty" object is stored in a list and the delete via 
context.deleteObject:

//Thios expression fetches all persons that should be deleted from a note
Expression delExp = 
ExpressionFactory.matchExp(Mappingnotizperson.TO_NOTIZ_PROPERTY, 
notiz.getObjectId()).andExp(ExpressionFactory.matchExp(Mappingnotizperson.TO_PERSONEN_PROPERTY, 
each.getObjectId()));

						SelectQuery selQ = new SelectQuery(Mappingnotizperson.class,delExp);

//perform the query
List<Mappingnotizperson> m = this.context.performQuery(selQ);
//Delete the object
this.context.deleteObject(m.get(0));
this.context.commitChanges();

Now the corresponding object is marked as transient and is deleted.

//This refetches all persons that are assigned to one note.
List<Mappingnotizperson> mapList = this.notiz.getMappingnotizpersonArray();
			System.err.println("notizid:"+ notizShow.getObjectId());
			for (Mappingnotizperson mappingnotizperson : mapList) {
				System.err.println("mapp: pers-state:" + 
mappingnotizperson.getPersistenceState()); // + " --- persid:" + 
mappingnotizperson.getToPersonen());
				this.persList.add(mappingnotizperson.getToPersonen()); //**
				this.existPers.add(mappingnotizperson.getToPersonen());
			}

** Here we get the NullPointerException that tells us, that the person of 
this mapping is null.

Hope you can start with what we've got.

To (2):

We're using cayenne 2.0.3 with a customized db adapter to be used with max 
db.

To me, the method prepareForAccess makes no sense.
At first it's checked againstz being hollow and afterwards it's checked 
against being commited - but how should it be commited when it's already 
hollow??

Thanks in advance guys.

Jan



>From: Kevin Menard <km...@servprise.com>
>Reply-To: user@cayenne.apache.org
>To: <us...@cayenne.apache.org>
>Subject: Re: To severe things
>Date: Thu, 13 Sep 2007 15:21:52 -0400
>
>Hi Jan,
>
>I'm snipping out a lot of just to get to a few basic questions I have.
>
>
>On 9/13/07 1:25 PM, "Jan Lendholt" <jl...@hotmail.com> wrote:
>
> > Well, this exception comes on an object with the PersistenceState =
> > Transient. The exception is thrown when in doResolveFault cayenne tries 
>to
> > access the object's context.
> > But why? This object shouldn't even be there! In my opinion this is a 
>bug.
> > It doesn't matter, if we delete the object with deletObject or with a 
>delet
> > query. How can it be? It's pretty severe though.
>
>If possible, could you please post the code that seems to trigger the 
>error?
>A small test case would be perfect, but showing anything would be helpful.
>
> > (2)
> > I try to access a mapping table again, this time we manage resources 
>like
> > rooms, beamers etc.
> >
> > I get all mappings and try to access via 
>mapping.getToResource().getname()
> > the resource's name.
> >
> > We get:
> >
> > 19:22:49.168 WARN!! Exception for /ams?serviceId=Echo.Synchronize
> > org.apache.cayenne.FaultFailureException: [v.@CAYENNE_VERSION@
> > @CAYENNE_BUILD_DATE@] Error resolving fault for ObjectId:
> > <ObjectId:Resource, IDRESOURCE=1> and state (hollow). Possible cause -
> > matching row is missing from the database.
>
>What version of Cayenne are you actually using?
>
>--
>Kevin
>

_________________________________________________________________
Haben Spinnen Ohren? Finden Sie es heraus – mit dem MSN Suche Superquiz via  
http://www.msn-superquiz.de  Jetzt mitmachen und gewinnen!


Re: To severe things

Posted by Kevin Menard <km...@servprise.com>.
Hi Jan,

I'm snipping out a lot of just to get to a few basic questions I have.


On 9/13/07 1:25 PM, "Jan Lendholt" <jl...@hotmail.com> wrote:

> Well, this exception comes on an object with the PersistenceState =
> Transient. The exception is thrown when in doResolveFault cayenne tries to
> access the object's context.
> But why? This object shouldn't even be there! In my opinion this is a bug.
> It doesn't matter, if we delete the object with deletObject or with a delet
> query. How can it be? It's pretty severe though.

If possible, could you please post the code that seems to trigger the error?
A small test case would be perfect, but showing anything would be helpful.

> (2)
> I try to access a mapping table again, this time we manage resources like
> rooms, beamers etc.
> 
> I get all mappings and try to access via mapping.getToResource().getname()
> the resource's name.
> 
> We get:
> 
> 19:22:49.168 WARN!! Exception for /ams?serviceId=Echo.Synchronize
> org.apache.cayenne.FaultFailureException: [v.@CAYENNE_VERSION@
> @CAYENNE_BUILD_DATE@] Error resolving fault for ObjectId:
> <ObjectId:Resource, IDRESOURCE=1> and state (hollow). Possible cause -
> matching row is missing from the database.

What version of Cayenne are you actually using?

-- 
Kevin


To severe things

Posted by Jan Lendholt <jl...@hotmail.com>.
Hey Folks,

me again and already 2 things I have to clear up:

(1)
We're savin some kind of notes in our system which can be assigned only to 
one person or to a list of persons.

Herefore we've got one table for the notes and a mapping table which saves 
the noteid and the id of the person.

Alright, so I creata note and add a person as a recipient. Now I re-open the 
window, remove the person i originally added to the note and add a new 
person to the note. I hit the save button and everything works fine.

When I try to re-open the note cayenne gives me a nice exception:

19:19:52.204 WARN!! Exception for /ams?serviceId=Echo.Synchronize
java.lang.NullPointerException
	at 
org.apache.cayenne.access.DataContextFaults$ToOneFault.doResolveFault(DataContextFaults.java:108)
	at 
org.apache.cayenne.access.DataContextFaults$ToOneFault.resolveFault(DataContextFaults.java:81)
	at 
org.apache.cayenne.CayenneDataObject.readProperty(CayenneDataObject.java:209)
	at 
ams.entities.auto._Mappingnotizperson.getToPersonen(_Mappingnotizperson.java:30)
	at 
ams.kalender.NotizCreateWindowPane.<init>(NotizCreateWindowPane.java:115)
	at ams.kalender.Kalender$4.actionPerformed(Kalender.java:315)
	at 
nextapp.echo2.app.button.AbstractButton.fireActionPerformed(AbstractButton.java:135)
	at 
nextapp.echo2.app.button.AbstractButton$1.actionPerformed(AbstractButton.java:100)
	at 
nextapp.echo2.app.button.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:70)
	at 
nextapp.echo2.app.button.DefaultButtonModel.doAction(DefaultButtonModel.java:58)
	at 
nextapp.echo2.app.button.AbstractButton.doAction(AbstractButton.java:121)
	at 
nextapp.echo2.app.button.AbstractButton.processInput(AbstractButton.java:506)
	at 
nextapp.echo2.app.update.ClientUpdateManager.process(ClientUpdateManager.java:116)
	at 
nextapp.echo2.app.update.UpdateManager.processClientUpdates(UpdateManager.java:89)
	at 
nextapp.echo2.webcontainer.ContainerSynchronizeService.renderUpdate(ContainerSynchronizeService.java:472)
	at 
nextapp.echo2.webrender.service.SynchronizeService.service(SynchronizeService.java:279)
	at 
nextapp.echo2.webrender.WebRenderServlet.process(WebRenderServlet.java:273)
	at 
nextapp.echo2.webrender.WebRenderServlet.doPost(WebRenderServlet.java:189)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:356)
	at 
org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:342)
	at 
org.apache.cayenne.conf.WebApplicationContextFilter.doFilter(WebApplicationContextFilter.java:91)
	at 
org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334)
	at 
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:286)
	at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
	at org.mortbay.http.HttpContext.handle(HttpContext.java:1776)
	at 
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:514)
	at org.mortbay.http.HttpContext.handle(HttpContext.java:1726)
	at org.mortbay.http.HttpServer.service(HttpServer.java:879)
	at org.mortbay.http.HttpConnection.service(HttpConnection.java:790)
	at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:952)
	at org.mortbay.http.HttpConnection.handle(HttpConnection.java:807)
	at 
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:196)
	at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
	at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:487)

Well, this exception comes on an object with the PersistenceState = 
Transient. The exception is thrown when in doResolveFault cayenne tries to 
access the object's context.
But why? This object shouldn't even be there! In my opinion this is a bug.
It doesn't matter, if we delete the object with deletObject or with a delet 
query. How can it be? It's pretty severe though.

(2)
I try to access a mapping table again, this time we manage resources like 
rooms, beamers etc.

I get all mappings and try to access via mapping.getToResource().getname() 
the resource's name.

We get:

19:22:49.168 WARN!! Exception for /ams?serviceId=Echo.Synchronize
org.apache.cayenne.FaultFailureException: [v.@CAYENNE_VERSION@ 
@CAYENNE_BUILD_DATE@] Error resolving fault for ObjectId: 
<ObjectId:Resource, IDRESOURCE=1> and state (hollow). Possible cause - 
matching row is missing from the database.
	at 
org.apache.cayenne.access.DataContext.prepareForAccess(DataContext.java:1816)
	at 
org.apache.cayenne.CayenneDataObject.readProperty(CayenneDataObject.java:202)
	at ams.entities.auto._Resource.getCapacity(_Resource.java:26)
	at 
ams.services.CayenneEventService.isResourceReserveable(CayenneEventService.java:373)
	at 
ams.resource.mgmt.ResourceReservationWindowPane.actionSave(ResourceReservationWindowPane.java:224)
	at 
ams.resource.mgmt.ResourceReservationWindowPane.access$6(ResourceReservationWindowPane.java:144)
	at 
ams.resource.mgmt.ResourceReservationWindowPane$4.actionPerformed(ResourceReservationWindowPane.java:467)
	at 
nextapp.echo2.app.button.AbstractButton.fireActionPerformed(AbstractButton.java:135)
	at echopointng.ButtonEx$1.actionPerformed(ButtonEx.java:120)
	at 
nextapp.echo2.app.button.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:70)
	at 
echopointng.model.DefaultButtonModelEx.doAction(DefaultButtonModelEx.java:51)
	at echopointng.ButtonEx.processInput(ButtonEx.java:203)
	at 
nextapp.echo2.app.update.ClientUpdateManager.process(ClientUpdateManager.java:116)
	at 
nextapp.echo2.app.update.UpdateManager.processClientUpdates(UpdateManager.java:89)
	at 
nextapp.echo2.webcontainer.ContainerSynchronizeService.renderUpdate(ContainerSynchronizeService.java:472)
	at 
nextapp.echo2.webrender.service.SynchronizeService.service(SynchronizeService.java:279)
	at 
nextapp.echo2.webrender.WebRenderServlet.process(WebRenderServlet.java:273)
	at 
nextapp.echo2.webrender.WebRenderServlet.doPost(WebRenderServlet.java:189)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:356)
	at 
org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:342)
	at 
org.apache.cayenne.conf.WebApplicationContextFilter.doFilter(WebApplicationContextFilter.java:91)
	at 
org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334)
	at 
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:286)
	at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
	at org.mortbay.http.HttpContext.handle(HttpContext.java:1776)
	at 
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:514)
	at org.mortbay.http.HttpContext.handle(HttpContext.java:1726)
	at org.mortbay.http.HttpServer.service(HttpServer.java:879)
	at org.mortbay.http.HttpConnection.service(HttpConnection.java:790)
	at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:952)
	at org.mortbay.http.HttpConnection.handle(HttpConnection.java:807)
	at 
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:196)
	at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
	at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:487)

i already checked all references again and again I always get this annoying 
message.
the data are there, at 100% all data and all constraints in the database are 
there. I double-checked everything.

Please, could someone help me?

thanks in advance!

Jan

_________________________________________________________________
Die neue MSN Suche Toolbar mit Windows-Desktopsuche. Suchen Sie gleichzeitig 
im Web, Ihren E-Mails und auf Ihrem PC! Jetzt neu! http://desktop.msn.de/ 
Jetzt gratis downloaden!


Re: possible bug / memory leak in DispatchQueue and EventManager?

Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Ayhan,

I applied the patch that is derived from the one suggested by Phil  
(his patch and comments finally made the cause of the leak obvious to  
me. Doh!):

    https://issues.apache.org/cayenne/browse/CAY-770

I'd appreciate if you could build the code from SVN and confirm that  
the fix worked. Then I'll close the issue. Let me know if you need  
help with the build.

Thanks
Andrus



On Feb 21, 2007, at 10:55 AM, Ayhan Kondoz wrote:

> Hi,
>
>
>
> i think i found a possible bug / memory leak within the  
> DispatchQueue and EventManager.
>
>
>
>
>
> First a little bit about my setup:
>
>
>
> I have 3 servers. Each server runs an axis service. The service  
> uses cayenne 1.2.1 to connect to a database. It reads customer and  
> account information from the DB etc..
>
> The servers are using cayenne's shared caching with javagroups as  
> the messaging service so that changes made from one server are  
> dispatched to the other servers.
>
>
>
> The avarage connections per second is somewhere around 4-5.
>
>
>
> However I have a very strange problem with this setup so I startet  
> to search for the reason. The problem is that with nearly constant  
> and unchanging usage the load of each server increases over time.  
> To further test this I created a test server with a similar setup.  
> There I created a test program that creates totally constant usage.  
> But even with the unchanging usage the load of the server is  
> increasing until the cpu load is so high that the requests can not  
> be processed anymore.
>
>
>
> I installed a java profiler to trying to pinpoint the location of  
> this error and this is what I found out.
>
>
>
> I let the server run for 24 hours and then stopped the program  
> which creates the test usage.
>
> But even while the server was idle there where still a lot of  
> instances in the java heap after the GC run.
>
>
>
> http://img206.imageshack.us/img206/9769/memorysy5.jpg
>
>
>
> Please note the HashMap, WeakReference and Invocation counts. I  
> pressume that the $ObjectProvider_*** is cayenne aswell but I am  
> not sure.
>
>
>
> Now the following image shows the cpu profile with incoming  
> connections.
>
>
>
> http://img339.imageshack.us/img339/2441/cpuci0.jpg
>
>
>
> As you can see 58% of the cpu time is used within HashSet.add().
>
>
>
> So when I consider the two facts i think that there might be a  
> possible problem with the EventManager. The first table tells us  
> that there are over 1 million instances of HashSet's and cayenne  
> Invocations. So it seems like the set's within the DispatchQueue  
> are not recycled properly so that the object count rises over time  
> which result in extremly high processtime when trying to add new  
> HashSet's.
>
>
>
>
>
> Thanks
>
> Ayhan
>
>
>
>
>
>
>
> Ayhan Kondoz
>
>
>
> Software-Entwicklung
>
>
>
> ---------------------------------------------------------------------- 
> ------------
>
> Telefon:    +49 (0) 40 513 06 616
>
> Telefax:    +49 (0) 40 513 06 998 616
>
> E-Mail:     ayhan.kondoz@freenet-ag.de <mailto:ayhan.kondoz@freenet- 
> ag.de>
>
> Website:  http://www.freenet.de <http://www.freenet.de/> ; http:// 
> www.freenet-ag.de <http://www.freenet-ag.de/>
>
> ---------------------------------------------------------------------- 
> ------------
>
> freenet.de AG
>
> Deelbögenkamp 4c
>
> 22297 Hamburg
>
> ---------------------------------------------------------------------- 
> ------------
>
> Vorsitzender des Aufsichtsrates: Prof. Dr. Helmut Thoma
>
> Vorstand: Eckhard Spoerr (Vors.),
> Axel Krieger, Stephan Esch, Eric Berger
>
> Amtsgericht Hamburg HRB 74048
>
>
>
>
>
> Diese Information ist ausschließlich für die adressierte Person  
> oder Organisation bestimmt und könnte vertrauliches und/oder  
> privilegiertes Material enthalten. Personen oder Organisationen,  
> für die diese Information nicht bestimmt ist, ist es nicht  
> gestattet, diese zu lesen, erneut zu übertragen, zu verbreiten,  
> anderweitig zu verwenden oder sich durch sie veranlasst zu sehen,  
> Maßnahmen irgendeiner Art zu ergreifen. Sollten Sie diese Nachricht  
> irrtümlich erhalten haben, bitten wir Sie, sich mit dem Absender in  
> Verbindung zu setzen und das Material von Ihrem Computer zu löschen.
>
>
>
> The information transmitted is intended only for the person or  
> entity to which it is addressed and may contain confidential and/or  
> privileged material. Any review, retransmission, dissemination or  
> other use of, or taking of any action in reliance upon, this  
> information by persons or entities other than the intended  
> recipient is prohibited. If you received this in error, please  
> contact the sender and delete the material from any computer.
>
>
>