[jboss-jira] [JBoss JIRA] (WFCORE-2292) HTTPS / Native Management protocol mismatch when using SSL

Ken Wills (JIRA) issues at jboss.org
Tue Feb 28 11:46:01 EST 2017


     [ https://issues.jboss.org/browse/WFCORE-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills resolved WFCORE-2292.
-------------------------------
    Resolution: Duplicate Issue


> HTTPS / Native Management protocol mismatch when using SSL
> ----------------------------------------------------------
>
>                 Key: WFCORE-2292
>                 URL: https://issues.jboss.org/browse/WFCORE-2292
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce8813189e66471c5b may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large.
> 1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl at 2ab25536
> 11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial at aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel at 787e0a1f
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192])
> ^^^^^^^
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192]
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF
> 11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream
> 11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl at 1cc4241b
> This was with native management, but I see the same thing using https. The client is jboss-cli.sh, connecting with:
> ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999 --user=admin --password=password 
> Relevant bits of config in use:
> {quote}
>  <management>
>   <security-realms>
>   <security-realm name="sslSecurityRealm">
>     <server-identities>
>       <ssl>
>         <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/>
>       </ssl>
>     </server-identities>
>     <authentication>
>         <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/>
>     </authentication>
>   </security-realm>
>  </security-realms>
>  <management-interfaces>
>    <native-interface security-realm="sslSecurityRealm">
>     <socket-binding native="native"/>
>     </native-interface>
>     </management-interfaces>
>  </management>
>     <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
>         <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
>         <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
>         <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/>
>     </socket-binding-group>
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


More information about the jboss-jira mailing list