Skip to main content

Server can get stuck in waiting status when creating new Threads

  • February 16, 2013
  • 0 replies
  • 0 views

Problem:

Server can get stuck in waiting status when creating new Threads

Resolution:

Title: Server can get stuck in waiting status when creating new Threads

* Full Product version(s) : 05.02.01.P18

* Full Platform version : All Platforms.

* JDK version : java 1.4.x

* Applicable component : QOS.

Problem Description

When using callback object and client periodically instantiates an object. The object reference of this object is passed to the server, and the server periodically calls the object"s method: ping(). This allows the server to know that the client still exists.

The problem is, that whenever the server calls the ping() method on a newly received IOR (received from the client), a new thread gets created in the server process, this new thread is stuck in a waiting state, even though the ping() operation, returns correctly

Java thread dump of the server process as follows (with a different name each time "Thread-..."):

"Thread-31" daemon prio=10 tid=0036deb0 nid=82 lwp_id=7961171 in

Object.wait() [0x4f8cb000..0x4f8cb4f0]

at java.lang.Object.wait(Native Method)

- waiting on (a com.inprise.vbroker.IIOP.WritingThread)

at java.lang.Object.wait(Object.java:429)

at com.inprise.vbroker.IIOP.WritingThread.run(Connection.java:40)

- locked (a com.inprise.vbroker.IIOP.WritingThread)

Solution:

The facts are:

(1) The timeout policy of RELATIVE_REQ_TIMEOUT is related with connection.write().

(2) The timeout policy of RELATIVE_RT_TIMEOUT is related with connection.read().

(3) If no timeout set for both policies, no doult this is the connection has the most fast speed.

(4) If RELATIVE_REQ_TIMEOUTis set, VisiBroker was creating another thread to monitor the send_timeout for the sending thread.

(5) If RELATIVE_RT_TIMEOUT is set, then the only overhead comes from socket.setSoTimeout

(6) if RELATIVE_RT_TIMEOUT is set and RELATIVE_REQ_TIMEOUT is not set, VisiBroker will detect that and adjust it by setting RELATIVE_REQ_TIMEOUT = RELATIVE_RT_TIMEOUT.

When timeout is set for the writing, VisiBroker uses a pooled thread to write data instead of each time creating a new thread for the writing.

Fundamentally, the IIOP.WritingThread is created on one per connection. Hence, if the connection is not closed, the Thread will be hanging around. Also, this thread is only created if the application uses Timeout policies.

Set connection idle timeout, this will reduce idle connections and hence the above concerned threads.

So use this property -- vbroker.se.iiop_tp.scm.iiop_tp.manager.idledTimeoutConnections=0.

also please apply following timeout properties along with the above property,

RELATIVE_REQ_TIMEOUT_POLICY_TYPE and

RELATIVE_RT_TIMEOUT_POLICY_TYPE.

Old KB# 26398

#VisiBroker
#Security