[jboss-user] [JNDI and Naming] - Re: EJB (SLSB) invocation ignores read timeout, blocks indef

[sumitsu]

Thanks to another forum post by someone with a simlar issue (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250461), I found a way to "seed" the invoker proxy returned by JNDI lookup with a desired read timeout value, thus enforcing the timeout upon each invocation of a service within the bean.

The timeout setting, somewhat counter-intuitively, is maintained on the server side rather than specified by the client; follow these steps to add the timeout value:

(1) Edit server/CONF/deploy/ejb3.deployer/META-INF/jboss-service.xml (where CONF is the container configuration you are using)

(2) Modify the mbean

  | <mbean code="org.jboss.remoting.transport.Connector"
  |        name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
  | 

(3) Alter the socket:// URI given by the InvokerLocator attribute to add the suffix /?timeout=#####, where ##### is the desired timeout value, in milliseconds

Upon the change to the configuration, the new timeout value is reflected in the client-side TRACE logs referencing a number to which the timeout value is set (which previously indicated a blocking timeout of 0).  Running the deliberate-stall test code detailed in the previous post produces a read timeout such as the following, where formerly it had stalled out:


  | java.lang.reflect.UndeclaredThrowableException
  | 	...
  | Caused by: java.rmi.MarshalException: Socket timed out.  Waited 5000 milliseconds for response while calling on InvokerLocator [socket://(node1):31516/?timeout=5000]; nested exception is: 
  | ...
  | Caused by: java.net.SocketTimeoutException: Read timed out
  | ...
  | 

It is confusing to me that this timeout is implemented as a server-side configuration rather than by obtaining it from the parameters (jnp.timeout and jnp.sotimeout) specified by the client when the JNDI context is created, since the latter option would seem to provide more flexibility to the client.  As it stands, this solution would appear to apply to all remote invocations to all EJB3 services running on the app server.

If anyone in the know regarding the design logic behind this approach would like to provide an explanation, I would be interested in hearing it.  (For that matter, if anyone knows of an alternative way to produce the same timeout effect, I would be interested in that as well.)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270022#4270022

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270022