Page 1 of 1
Use of java.util.treemap and Scheduler
Posted: 09 Jul 2009, 10:29
by ichimaru
Hello there all,
Does anyone know in what way smartfox makes use of a TreeMap? We are having terrible memory leaks and java.util.TreeMap always seems to be on top of the heap usage. We do not use any TreeMaps so I was wondering if smartfox itself uses this datastructure heavily?
As our server is now running longer we have had another very strange problem on 3 occasions now. Our rooms depend heavily on the scheduler (we draw balls in intervals) and on some occasions the scheduler stops in all the rooms at once. Does anyone else ever had this problem? And if so, what did you find out?
We can get a reference to the scheduler through a singleton. In the constructor of the zone the scheduler is started. Every room gets a reference to the scheduler and uses it for different tasks. The rooms are never destroyed (we only have 10 static rooms) so the scheduler is also never destroyed. Also strange is that we do not get any excpetions of any type.
We use smartfox version 1.6.6
I hope someone can help us with this project breaking problems.
Thanks in advance!
Posted: 10 Jul 2009, 07:22
by Lapo
Hi,
there's no use of the TreeMap class in the whole SmartFoxServer code. I can assure you. It is likely, however, that some other libraries use that internally. It is the very first time that we get a similar report and there is no know memory leak related to TreeMap(s) so I would need more infos.
The fact that TreeMap objects are at the top of the instances count does not necessarily mean it's a memory leak.
Do you see the memory constantly growing? Are you getting an OutOfMemoryException?
As our server is now running longer we have had another very strange problem on 3 occasions now. Our rooms depend heavily on the scheduler (we draw balls in intervals) and on some occasions the scheduler stops in all the rooms at once. Does anyone else ever had this problem? And if so, what did you find out?
You should check your logs for errors. It's likely you will find exceptions that can help tracking the problem
We can get a reference to the scheduler through a singleton.
Can you explain how the Singleton is implemented?
Posted: 10 Jul 2009, 07:38
by ichimaru
Hello Lapo, thanks for your answer
Lapo wrote:Hi,
The fact that TreeMap objects are at the top of the instances count does not necessarily mean it's a memory leak.
Do you see the memory constantly growing? Are you getting an OutOfMemoryException?
We see our memory steadily jigsawing its way to our max memory setting (4 GB) and when it reaches its max the VM probably collapses because the whole server crashes. (and we have to physically restart the server, even a kill -9 does not work)
You should check your logs for errors. It's likely you will find exceptions that can help tracking the problem
That is the strange thing, nothing appears in the log files. The scheduler thread just seems stop for no particular reason....
Can you explain how the Singleton is implemented?
Of course, The scheduler code is posted below
Code: Select all
public class SchedulerSingleton {
private static Scheduler scheduler;
private SchedulerSingleton() {
}
public static synchronized Scheduler getScheduler() {
if (scheduler == null) {
scheduler = new Scheduler();
scheduler.startService();
}
return scheduler;
}
// Cloning also not allowed!
@Override
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
Thanks again!
Posted: 10 Jul 2009, 07:52
by Lapo
Hi,
We see our memory steadily jigsawing its way to our max memory setting (4 GB) and when it reaches its max the VM probably collapses because the whole server crashes. (and we have to physically restart the server, even a kill -9 does not work)
I see. I don't know what you use for debugging/profiling (VisualVM?), anyways I think it shouldn't be too difficult to identify the possible culprit by taking a look at the other frequent object instantiations. The objects using those TreeMaps should also keep growing and never go away.
I would also suggest to take some time and review your server side code looking for possible unreleased objects. It sounds a lot like you're creating many objects that are never released.
The Singleton looks good, however each Extension is loaded under a different ClassLoader. Are you sure it's really working as expected?
Essentially this depends on the fact that the
javaExtensions/ folder is added to your classpath or not.
If it is, then your extension classes are loaded by the System Class Loader and it will work out of the box. Otherwise it will not.
Posted: 10 Jul 2009, 08:32
by ichimaru
Thanks for your response again Lapo
The Singleton looks good, however each Extension is loaded under a different ClassLoader. Are you sure it's really working as expected?
Essentially this depends on the fact that the javaExtensions/ folder is added to your classpath or not.
If it is, then your extension classes are loaded by the System Class Loader and it will work out of the box. Otherwise it will not.
The javaExtensions folder is added to the classpath. And even if each extension is loaded by a different classloader I would not see any problems arising ( every extension creates its own scheduler and starts its then).
When the the above two problems do not arise the game functions properly (400 persons are now playing the game
).
I will further inverstigate my server side logic but the written extension is not very big. In short, when a game starts I create a gameState object which saves the current gamestate (fallen balls, which users have which tickets and balls etc). When a game is finished, game statistics are written to a database and then every instance variable of the gameState object is null referenced and then the gameState itself is null referenced.
My thanks again
[/quote]
Posted: 10 Jul 2009, 08:45
by Lapo
The javaExtensions folder is added to the classpath. And even if each extension is loaded by a different classloader I would not see any problems arising ( every extension creates its own scheduler and starts its then).
In this case the Singleton is seen as the same class by all extensions because each different ClassLoader has the same parent, which is the System ClassLoader. So your singleton works as expected.