File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Distributed Java and the fly likes Borland Visibroker, WebSphere, Threads and WorkManagers Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Distributed Java
Bookmark "Borland Visibroker, WebSphere, Threads and WorkManagers" Watch "Borland Visibroker, WebSphere, Threads and WorkManagers" New topic
Author

Borland Visibroker, WebSphere, Threads and WorkManagers

Luiz Eduardo Guida Valmont
Greenhorn

Joined: Mar 23, 2009
Posts: 3
Hello folks,

The Problem - A not so short intruduction

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"):

http://74.125.95.132/search?q=cache:Kat4mnv8Yl8J:support.borland.com/entry.jspa%3FexternalID%3D4858+site:support.borland.com+borland+visibroker+4.5+tcpTimeout&cd=1&hl=pt-BR&ct=clnk&client=iceweasel-a

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.

I also found this:

http://techpubs.borland.com/am/visibroker/v80/en/VisiBroker_Doc_updates.htm

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."
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Borland Visibroker, WebSphere, Threads and WorkManagers