Sure did [sorry for the late response]. I posted a similar question in the JBoss Remoting Forum, and someone pointed me toward using the JBoss Unified Invoker to accomplish this. The thread in the JBoss Remoting Forum is http://www.jboss.org/index.html?module=bb&op=viewtopic&t=152317. At a high level, the Sun RMI timeout parameters don't work for the communication between the clients and the server because they don't use the Sun RMI libraries for their communication; they use the JBoss Remoting libraries. So in order to get the timeouts to work, you have to configure the JBoss Remoting libraries. To do so, you have to define the UnifiedInvoker in the jboss-service.xml and set the timeouts for it. You do that in the following file: - <jboss_home>/server/<app_name>/conf/jboss-service.xml Next you have to tell JBoss that your remote EJBs should use the configured UnifiedInvoker for their communication. You do this in the following file: - <jboss_home>/server/<app_name>/conf/standardjboss.xml I basically followed the instructions in the following document: http://docs.jboss.org/jbossas/unified_invoker/UnifiedInvoker_guide.html For reference, the steps I followed and the resulting configuration changes are below: First I added the UnifiedInvoker configuration to my jboss-service.xml. The full configuration is below. The "timeout" attribute is the one that actually times out the sockets: <!-- Changes to Support the Unified Invoker: | http://docs.jboss.org/jbossas/unified_invoker/UnifiedInvoker_guide.html#d0e9 | --> | | <!-- Unified invoker (based on remoting) --> | <mbean code="org.jboss.invocation.unified.server.UnifiedInvoker" | name="jboss:service=invoker,type=unified"> | <!-- To turn on strict RMI exception propagation uncomment block below --> | <!-- This will cause the UnifiedInvokerProxy to wrap RemoteExceptions --> | <!-- within a ServerException, otherwise will throw root exception --> | <!-- (not RemoteException) --> | <!-- <attribute name="StrictRMIException">true</attribute> --> | <depends>jboss:service=TransactionManager</depends> | <depends>jboss.remoting:service=Connector,transport=socket</depends> | </mbean> | | <!-- The Connector is the core component of the remoting server service. --> | <!-- It binds the remoting invoker (transport protocol, callback configuration, --> | <!-- data marshalling, etc.) with the invocation handlers. --> | <mbean code="org.jboss.remoting.transport.Connector" | xmbean-dd="org/jboss/remoting/transport/Connector.xml" | name="jboss.remoting:service=Connector,transport=socket" | display-name="Socket transport Connector"> | <!-- Can either just specify the InvokerLocator attribute and not the invoker element in the --> | <!-- Configuration attribute, or do the full invoker configuration in the in invoker element --> | <!-- of the Configuration attribute. --> | | <!-- Remember that if you do use more than one param on the uri, will have to include as a CDATA, --> | <!-- otherwise, parser will complain. --> | <!-- <attribute name="InvokerLocator"><![CDATA[socket://${jboss.bind.address}:4446/?datatype=invocation]]></attribute> --> | | <attribute name="Configuration"> | <!-- Using the following <invoker> element instead of the InvokerLocator above because specific attributes needed. --> | <!-- If wanted to use any of the parameters below, can just add them as parameters to the url above if wanted use the InvokerLocator attribute. --> | <config> | <!-- Other than transport type and handler, none of these configurations are required (will just use defaults). --> | <invoker transport="socket"> | <attribute name="dataType" isParam="true">invocation</attribute> | <attribute name="marshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationMarshaller</attribute> | <attribute name="unmarshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationUnMarshaller</attribute> | <!-- This will be port on which the marshall loader port runs on. --> | <!-- <attribute name="loaderport" isParam="true">4447</attribute> --> | <!-- The following are specific to socket invoker --> | <attribute name="numAcceptThreads">100</attribute> | <attribute name="maxPoolSize">2500</attribute> | <!-- <attribute name="clientMaxPoolSize" isParam="true">304</attribute>--> | <attribute name="socketTimeout" isParam="true">300000</attribute> | <!--Set the all important client side socket timeout to 5 minutes. --> | <attribute name="timeout" isParam="true">300000</attribute> | <attribute name="serverBindAddress">${jboss.bind.address}</attribute> | <attribute name="serverBindPort">4446</attribute> | <!-- <attribute name="clientConnectAddress">216.23.33.2</attribute> --> | <!-- <attribute name="clientConnectPort">7777</attribute> --> | <!-- <attribute name="enableTcpNoDelay" isParam="true">true</attribute> --> | <!-- <attribute name="backlog">200</attribute>--> | <!-- The following is for callback configuration and is independent of invoker type --> | <!-- <attribute name="callbackMemCeiling">30</attribute>--> | <!-- indicates callback store by fully qualified class name --> | <!-- <attribute name="callbackStore">org.jboss.remoting.CallbackStore</attribute>--> | <!-- indicates callback store by object name --> | <!-- <attribute name="callbackStore">jboss.remoting:service=CallbackStore,type=Serializable</attribute> --> | <!-- config params for callback store. if were declaring callback store via object name, --> | <!-- could have specified these config params there. --> | <!-- StoreFilePath indicates to which directory to write the callback objects. --> | <!-- The default value is the property value of 'jboss.server.data.dir' and if this is not set, --> | <!-- then will be 'data'. Will then append 'remoting' and the callback client's session id. --> | <!-- An example would be 'data\remoting\5c4o05l-9jijyx-e5b6xyph-1-e5b6xyph-2'. --> | <!-- <attribute name="StoreFilePath">callback</attribute>--> | <!-- StoreFileSuffix indicates the file suffix to use for the callback objects written to disk. --> | <!-- The default value for file suffix is 'ser'. --> | <!-- <attribute name="StoreFileSuffix">cst</attribute>--> | </invoker> | | <!-- At least one handler is required by the connector. If have more than one, must declare --> | <!-- different subsystem values. Otherwise, all invocations will be routed to the only one --> | <!-- that is declared. --> | <handlers> | <!-- can also specify handler by fully qualified classname --> | <handler subsystem="invoker">jboss:service=invoker,type=unified</handler> | </handlers> | </config> | </attribute> | <depends>jboss.remoting:service=NetworkRegistry</depends> | </mbean> | | <mbean code="org.jboss.remoting.network.NetworkRegistry" | name="jboss.remoting:service=NetworkRegistry"/> | | <!-- Done with changes for the Unified Invoker --> | I added the following to my standardjboss.xml file which defines an EJB invoker that should use the UnifiedInvoker previously configured in the jboss-service.xml: | <!-- A configuration for Stateless Session beans that tells then to use the unified invoker rather than the rmi one. | This gives us the ability to specify a client-side socket timeout. We tell the stateless session beans to use | this configuration in the "Standard Stateless SessionBean" configuration below. | --> | <invoker-proxy-binding> | <name>stateless-unified-invoker</name> | <invoker-mbean>jboss:service=invoker,type=unified</invoker-mbean> | <proxy-factory>org.jboss.proxy.ejb.ProxyFactory</proxy-factory> | <proxy-factory-config> | <client-interceptors> | <home> | <interceptor>org.jboss.proxy.ejb.HomeInterceptor</interceptor> | <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor> | <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor> | <interceptor call-by-value="false">org.jboss.invocation.InvokerInterceptor</interceptor> | <interceptor call-by-value="true">org.jboss.invocation.MarshallingInvokerInterceptor</interceptor> | </home> | <bean> | <interceptor>org.jboss.proxy.ejb.StatelessSessionInterceptor</interceptor> | <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor> | <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor> | <interceptor call-by-value="false">org.jboss.invocation.InvokerInterceptor</interceptor> | <interceptor call-by-value="true">org.jboss.invocation.MarshallingInvokerInterceptor</interceptor> | </bean> | </client-interceptors> | </proxy-factory-config> | </invoker-proxy-binding> | The last step is to tell your EJBs to use the invoker defined above. In my case, I told my stateless Session EJBs to use it by editing the "Standard Stateless SessionBean" configuration in the standardjboss.xml. My full "Standard Stateless SessionBean configuration is below": | <container-configuration> | <container-name>Standard Stateless SessionBean</container-name> | <call-logging>false</call-logging> | <!--Tell the stateless session bean to use the unified session bean invoker so that we can specify client socket timeouts. --> | <invoker-proxy-binding-name>stateless-unified-invoker</invoker-proxy-binding-name> | <container-interceptors> | <interceptor>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor</interceptor> | <interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor> | <interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor> | <!-- CMT --> | <interceptor transaction="Container">org.jboss.ejb.plugins.TxInterceptorCMT</interceptor> | <interceptor transaction="Container">org.jboss.ejb.plugins.CallValidationInterceptor</interceptor> | <interceptor transaction="Container">org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor</interceptor> | <!-- BMT --> | <interceptor transaction="Bean">org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor</interceptor> | <interceptor transaction="Bean">org.jboss.ejb.plugins.TxInterceptorBMT</interceptor> | <interceptor transaction="Bean">org.jboss.ejb.plugins.CallValidationInterceptor</interceptor> | <interceptor>org.jboss.resource.connectionmanager.CachedConnectionInterceptor</interceptor> | </container-interceptors> | <instance-pool>org.jboss.ejb.plugins.StatelessSessionInstancePool</instance-pool> | <instance-cache></instance-cache> | <persistence-manager></persistence-manager> | <container-pool-conf> | <MaximumSize>100</MaximumSize> | </container-pool-conf> | </container-configuration> | That's it. I did some testing and it worked properly. We put this change into production 2 months ago (over 1000 clients attached to our server), and we haven't seen any issues so far, so I'm fairly confident that it works as expected. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250461#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...