[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [geclipse-dev] Job Status
|
Hi All,
In any case I did never really catch the point why we have to have one job status updater per job. We also do not have one Java VM per class which would of course be a lot of overhead, right?! I know that there are arguments in the direction of network balancing etc., but in fact that could also be implemented in a singleton.
I do not know if the job status updaters are really the reason for Romains memory problems or if something else is going wrong. Nevertheless I strongly vote for changing the job status updater code to make use of a single(ton) update manager rather than one updater per job!
Concerning the memory problem Romain reported. What are the investigations here? Has anybody already tried to submit a thousand jobs? What are the observations? This is a severe problem and we have to find a solution!
Cheers, Mathias
-----Original Message-----
From: geclipse-dev-bounces@xxxxxxxxxxx on behalf of Ariel Garcia
Sent: Thu 9/25/2008 4:16 PM
To: Developer mailing list
Subject: Re: [geclipse-dev] Job Status
> Actually several million instances of GridJobStatus are potentially
> created during one execution.
Looking at
eu.geclipse.core.jobs.GridJob.getJobStatus() and readJobStatus()
i do not see "millions" of GridJobStatus objects being created
for "thousands" of jobs but rather it seems to me a O(1) relationship...
each GridJob has its own private GridJobStatus copy being returned,
new GridJobStatus()
being called only if there is no status etc
But for sure Mariusz will enlighten me ;-)
Ariel
_______________________________________________
geclipse-dev mailing list
geclipse-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/geclipse-dev
