This content has been marked as final. Show 5 replies
The stacktrace will show you where/why the ResourceLimitError is being thrown. You will be trying to create too many threads, or using too many timers - something of that nature.
You have a quad-core machine versus a dual-core so the scheduling of your application will be quite different and that could lead to things getting out of balance and lead to resource exhaustion. It all depends on what your application logic is doing.
Strange thing happened. Before I have written my post, I have checked the internet but did not find much info. After David's post I have looked in "The Real-Time Specification for Java" by Bollella, Gosling et. al, on exception they also say the same thing (javadoc) "Locks". OK. I thought I should check what is these locks. There is a class provides information about these things called RealtimeSystem. I used getMaximumConcurretLocks() and getConcurrentLocksUsed() methods to find out what was my lock count on other system, it was huge, I had 2'147'483'647 lock, OK there was no way I used all these locks. So I added same line of code which printted info about lock on new system and run it. It was running but my screen was not coming, first I thought I will kill the process and restart but I said be patient and about 3-5 minutes later my screen came up and my application was working and lock counts were the same, actually I was not using any locks. Shame, one has so much locks and not using single one. OK. I think I should learn more about locks. But what happened in these 5 minute when I include print info about locks is a mystery to me. May be David can say thing about this. But application works fine and CPU load reduced significantly.
Now I can hit the road to show everybody how nice is the RealTime Java supporting our software and simulation. It is at least better thing to do than wait for Oracle to decide what to do with RealTime Java. I hope they will decide soon because I am signing contacts with RealTime Java without knowing if I will be able to buy it at all.
As I said originally the stacktrace for the exception should show you what was being attempted when the exception was thrown. The most common resource limits you will encounter with Java RTS are running out of native thread resources (when you start a thread) either the thread itself or the cyclic, or running out of timers (when you create the deadline miss handler for an async-event, or create a javax.realtime.Timer)
- com.sun.rstjx.Semaphore creation
- failure to initialize the thread pools used by async event handlers
The RTSJ description for ResourceLimitError states:
"Thrown if an attempt is made to exceed a system resource limit, _such as) the maximumnumber of locks."
Note the "such as". "locks" is only an example, and only applicable if your implementation has an inherent limit on the number of locks.