-
Bug
-
Resolution: Done
-
Critical
-
7.0.4.GA, 7.1.0.ER3, 7.2.0.CD14
- A client will be blocked if a network connection to the server is broken or the server machine has power loss.
The time until the client can continue seems the network timeout.
org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:413)
This is normally avoided by set
connect.options.org.xnio.Options.READ_TIMEOUT
connect.options.org.xnio.Options.KEEP_ALIVE"
connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL
But the properties don't make a difference for EAP7 client.
if the property invocation.timeout is set the invocation failed and the client might continue if there are more servers or a cluster view.
But it will stuck on exit if the connection should be closed at org.jboss.remoting3.spi.AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:190)
This is the same even if the server connector has changed from http-remoting to remoting.
If the client use the EAP6.4.14 jboss-client.jar the properties take effect and the client will fail imediately - for sure the server use the old connector protocol -
this will be a huge drawback in failover scenarios
- is caused by
-
XNIO-296 READ_TIMEOUT and WRITE_TIMEOUT options not set when opening new channel
- Resolved
- is cloned by
-
JBEAP-12670 [GSS](7.1.z) EJB client gets stuck in awaitResponse or AbstractHandleableCloseable when server is disconnected from network
- Closed
- is incorporated by
-
JBEAP-11358 Upgrade XNIO to 3.5.0.Beta7
- Closed
- is related to
-
JBEAP-8577 [GSS](7.0.z) SSL EJB Client stuck in AbstractHandleableCloseable.close
- Closed
- relates to
-
JBEAP-13911 [EAT](7.1.z) Testcase for JBEAP-12670
- Closed