Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-12799

[GSS](7.0.z) XNIO000812: Connection closed unexpectedly

    XMLWordPrintable

Details

    • Bug
    • Resolution: Won't Do
    • Major
    • None
    • 7.0.7.GA
    • EJB, Remoting
    • None
    • +
    • Workaround Exists
    • Hide

      If using an EAP server use a "jboss-ejb-client.xml" to connect to the EJB (issue disappear).
      If using a standalone java use "jboss-ejb-client.properties" (issue is minimized cos only a few connections are created and re-used although the exception is still there in the context creation).

      The CLOSE_WAIT issue only happens if a lot of connections are created.

      Show
      If using an EAP server use a "jboss-ejb-client.xml" to connect to the EJB (issue disappear). If using a standalone java use "jboss-ejb-client.properties" (issue is minimized cos only a few connections are created and re-used although the exception is still there in the context creation). The CLOSE_WAIT issue only happens if a lot of connections are created.
    • Hide

      1) Configure a instance using domain configuration and setup an HTTPS port.
      host.xml:

                  <security-realm name="CertificateRealm">
                <server-identities>
                    <ssl>
                        <keystore path="/opt/jboss/jboss-eap-7.0/domain/configuration/keystore.jks" keystore-password="changeit" alias="jboss"/>
                    </ssl>
                </server-identities>
                <authentication>
                    <truststore path="/opt/jboss/jboss-eap-7.0/domain/configuration/cacerts" keystore-password="changeit"/>
                </authentication>
            </security-realm>

      domain.xml (full-ha profile):

           <https-listener name="https" secure="true" security-realm="CertificateRealm" socket-binding="https"/>

      2) Configure the HTTPS port to be the remoting one:

           <http-connector name="http-remoting-connector" connector-ref="https" security-realm="ApplicationRealm"/>

      3) Modify "sample-ejb" application (file "client.properties") to point to your environment (mainly "java.naming.provider.url", "java.naming.security.principal" and "java.naming.security.credentials").

      4) Package and deploy the application.

      5) The application can be tested using the servlets or standalone client:
      a) Servlet:
      https://host:port/sample-ejb/CalculatorClientServlet
      https://host:port/sample-ejb/CounterClientServlet
      b) Standalone application:
      java -Djava.net.preferIPv4Stack=true -Djavax.net.ssl.trustStore=cacerts -cp jboss-client.jar:target/classes/ com.redhat.sample.client.CalculatorClient 1 1
      java -Djava.net.preferIPv4Stack=true -Djavax.net.ssl.trustStore=cacerts -cp jboss-client.jar:target/classes/ com.redhat.sample.client.CounterClient 3

      You should see the exception everytime the context is created (if you use "default" profile, non-clustered, the issue doesn't happen).

      Show
      1) Configure a instance using domain configuration and setup an HTTPS port. host.xml: <security-realm name="CertificateRealm"> <server-identities> <ssl> <keystore path="/opt/jboss/jboss-eap-7.0/domain/configuration/keystore.jks" keystore-password="changeit" alias="jboss"/> </ssl> </server-identities> <authentication> <truststore path="/opt/jboss/jboss-eap-7.0/domain/configuration/cacerts" keystore-password="changeit"/> </authentication> </security-realm> domain.xml (full-ha profile): <https-listener name="https" secure="true" security-realm="CertificateRealm" socket-binding="https"/> 2) Configure the HTTPS port to be the remoting one: <http-connector name="http-remoting-connector" connector-ref="https" security-realm="ApplicationRealm"/> 3) Modify "sample-ejb" application (file "client.properties") to point to your environment (mainly "java.naming.provider.url", "java.naming.security.principal" and "java.naming.security.credentials"). 4) Package and deploy the application. 5) The application can be tested using the servlets or standalone client: a) Servlet: https://host:port/sample-ejb/CalculatorClientServlet https://host:port/sample-ejb/CounterClientServlet b) Standalone application: java -Djava.net.preferIPv4Stack=true -Djavax.net.ssl.trustStore=cacerts -cp jboss-client.jar:target/classes/ com.redhat.sample.client.CalculatorClient 1 1 java -Djava.net.preferIPv4Stack=true -Djavax.net.ssl.trustStore=cacerts -cp jboss-client.jar:target/classes/ com.redhat.sample.client.CounterClient 3 You should see the exception everytime the context is created (if you use "default" profile, non-clustered, the issue doesn't happen).

    Description

      When using EJB remoting over HTTPS with a cluster installation (for example using domain with "full-ha" profile) the following exception is thrown when the context is created:

       XNIO000812: Connection closed unexpectedly
        at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:416)
        at org.xnio.http.HttpUpgrade$HttpUpgradeState.flushUpgradeChannel(HttpUpgrade.java:369)
        at org.xnio.http.HttpUpgrade$HttpUpgradeState.access$900(HttpUpgrade.java:165)
        at org.xnio.http.HttpUpgrade$HttpUpgradeState$ConnectionOpenListener.handleEvent(HttpUpgrade.java:340)
        at org.xnio.http.HttpUpgrade$HttpUpgradeState$ConnectionOpenListener.handleEvent(HttpUpgrade.java:320)
        at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
        at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:330)
        at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
        at ...asynchronous invocation...(Unknown Source)
        at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:294)
        at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:430)
        at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
        at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
        at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:78)
        at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
        at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79)
        at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:512)
        at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:486)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)

      When creating a lot of new connections some connections seem to be leaked in CLOSE_WAIT status.

      This issue does not happen if "jboss-ejb-client.xml" (eap to eap) is used.

      Attachments

        1. domain.xml.zip
          7 kB
        2. sample-ejb.zip
          142 kB

        Issue Links

          is related to

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-12105 [GSS](7.0.z) [Remoting] SSL EJB Client stuck in AbstractHandleableCloseable.close with shortlived clients and when server is disconnected from network - part 2

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Verified

          Activity

            People

              Unassigned Unassigned
              rhn-support-rmartinc Ricardo Martin Camarero
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: