This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I'm working on an issue concerning excessive usage of java.lang.Thread. The solution is porting the uses of that class to the Work and WorkManager classes. There's one external system to which my application must talk and the interface is, not surprisingly, CORBA. That said, there's the time out issue. The old implementation used sleep'ing and interrupting to do that but the new one must not.
After some google'ing, I found that vbroker.orb.qos.relativeRTT seemed to be the answer I was looking for. That's when I stumbled upon this link (look for "CR5796"):
relativeRTT raising my thread count is not an option. I cannot cut the "pure" Thread usage for something that uses a lot of threads itself. Searching for "site:borland.com Case 606574" yields that link again.
setting vbroker.orb.tcpTimeout to an Integer or a Long value yields an Exception-That-Must-Not-Be-Named (aka NullPointerException). Moreover, using deprecated stuff is not good in the long run.
The Question(s) - Finally
Does the issue as reported by "Case 606574" (high thread count when using relativeRTT) still holds? Does anyone have any proof or link on the issue? Does relativeRTT mean any, even a single, call to java.lang.Thread constructor?
If I'm not clear enough please bear with me and by all means tell me what you don't understand.
"Science, like nature, must also be tamed with a view towards its preservation."