-
Bug
-
Resolution: Done
-
Critical
-
7.0.4.GA, 7.1.0.ER3
-
-
-
-
-
-
The testcase using the wildfly-config.xml of https://issues.jboss.org/browse/JBEAP-13911 succeeds on Jenkins.
-
Workaround Exists
-
-
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
- clones
-
JBEAP-10038 [GSS](7.2.0) EJB client gets stuck in awaitResponse or AbstractHandleableCloseable when server is disconnected from network
- Closed
- is caused by
-
XNIO-296 READ_TIMEOUT and WRITE_TIMEOUT options not set when opening new channel
- Resolved
- is cloned by
-
JBEAP-10259 [GSS](7.0.z) XNIO-296 - READ_TIMEOUT and WRITE_TIMEOUT options not set when opening new channel
- Closed
- is incorporated by
-
JBEAP-11358 Upgrade XNIO to 3.5.0.Beta7
- Closed
- is related to
-
JBEAP-9015 [GSS](7.1.0) SSL EJB Client stuck in AbstractHandleableCloseable.close
- Closed
- relates to
-
JBEAP-13911 [EAT](7.1.z) Testcase for JBEAP-12670
- Closed
- links to