[JBoss JIRA] (WFLY-1805) It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-1805?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink reassigned WFLY-1805:
--------------------------------------
Assignee: David Lloyd
> It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1805
> URL: https://issues.jboss.org/browse/WFLY-1805
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Labels: ejb
>
> With former JBoss versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors.
> Since AS7 and WildFly the only possibility is to pass such context from the client to the server.
> It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations.
> This was used to return i.e. tracking or additional usefull informations.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8087) Statistics Resources are being created without a corresponding ManagementResourceRegistration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8087?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-8087:
-----------------------------------
Priority: Minor (was: Major)
> Statistics Resources are being created without a corresponding ManagementResourceRegistration
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-8087
> URL: https://issues.jboss.org/browse/WFLY-8087
> Project: WildFly
> Issue Type: Bug
> Components: JCA, JMS
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> While working on WFCORE-2286 I discovered that there are resources in the tree, at least on the DC, for which there is no corresponding MRR. I believe [~pferraro] in some recent work he's done has stumbled on a similar thing.
> I found there were no MRRs for
> /profile=*/subsystem=messaging-activemq/server=*/pooled-connection-factory=*/statistics=pool
> /profile=*/subsystem=datasources/data-source=*/statistics=jdbc
> /profile=*/subsystem=datasources/data-source=*/statistics=pool
> I expect the latter two would be repeated for xa-data-source=*
> Probably the lack of MRR is correct and the problem is the existence of the resource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8087) Statistics Resources are being created without a corresponding ManagementResourceRegistration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8087?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-8087:
----------------------------------------
A bit more on why this happens.
We don't know if the statistics resource is going to be needed until Stage.RUNTIME, as the statistics-enabled attribute allows expressions. Plus, we don't know the exact statistics that will be available until runtime, as those are dependent on the DS/RA implementation. So, the MRR is not registered until RUNTIME. But we don't allow Resource tree changes after Stage.MODEL, and the MSC Service that does the MRR reg can't safely hold a ref to the Resource tree beyond the scope of one op anyway (since a later write op will clone the tree leaving the service with an stale copy.) So to work around this the child statistics resource is always added.
A partial improvement on this is to not add it on an HC, since it's never relevant there and the MRR will never be added. My PR does that.
> Statistics Resources are being created without a corresponding ManagementResourceRegistration
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-8087
> URL: https://issues.jboss.org/browse/WFLY-8087
> Project: WildFly
> Issue Type: Bug
> Components: JCA, JMS
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> While working on WFCORE-2286 I discovered that there are resources in the tree, at least on the DC, for which there is no corresponding MRR. I believe [~pferraro] in some recent work he's done has stumbled on a similar thing.
> I found there were no MRRs for
> /profile=*/subsystem=messaging-activemq/server=*/pooled-connection-factory=*/statistics=pool
> /profile=*/subsystem=datasources/data-source=*/statistics=jdbc
> /profile=*/subsystem=datasources/data-source=*/statistics=pool
> I expect the latter two would be repeated for xa-data-source=*
> Probably the lack of MRR is correct and the problem is the existence of the resource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2293) Centrally define sensitivity classifications for references to Elytron capabilities.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2293?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2293:
------------------------------------------
[~dlofthouse] By "Credential Store" you're basically talking about credential reference attributes, right? If so, yeah, that's analogous to the existing username/password type attribute where we use SensitivityClassification.CREDENTIAL.
> Centrally define sensitivity classifications for references to Elytron capabilities.
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-2293
> URL: https://issues.jboss.org/browse/WFCORE-2293
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Beta1
>
>
> Predominantly the following 6 items are referenced across the application server: -
> Authentication Context
> Credential Store
> HTTP Authentication Factory
> SASL Authentication Factory
> SSLContext
> Security Domain
> We should probably represent these as: -
> (Authentication Context) -> Client Security Ref
> (Credential Store) -> Credential
> (HTTP / SASL Authentication Factory) -> Authentication Factory Ref
> (Security Domain) -> Security Domain Ref
> (SSL Context) -> SSL Ref
> We already have 'Credential' defined so we can re-use that.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2293) Centrally define sensitivity classifications for references to Elytron capabilities.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-2293:
----------------------------------------
Summary: Centrally define sensitivity classifications for references to Elytron capabilities.
Key: WFCORE-2293
URL: https://issues.jboss.org/browse/WFCORE-2293
Project: WildFly Core
Issue Type: Task
Components: Domain Management, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 3.0.0.Beta1
Predominantly the following 6 items are referenced across the application server: -
Authentication Context
Credential Store
HTTP Authentication Factory
SASL Authentication Factory
SSLContext
Security Domain
We should probably represent these as: -
(Authentication Context) -> Client Security Ref
(Credential Store) -> Credential
(HTTP / SASL Authentication Factory) -> Authentication Factory Ref
(Security Domain) -> Security Domain Ref
(SSL Context) -> SSL Ref
We already have 'Credential' defined so we can re-use that.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2292) HTTPS / Native Management protocol mismatch when using SSL
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2292?page=com.atlassian.jira.plugi... ]
Ken Wills updated WFCORE-2292:
------------------------------
Description:
It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce88... 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@2ab25536
11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel@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@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}
was:
It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce88... 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@2ab25536
11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel@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@1cc4241b
This was with native management, but I see the same thing using https.
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}
> 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/77158040d82d74af33800fce88... 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@2ab25536
> 11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel@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@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)
9 years, 2 months
[JBoss JIRA] (WFCORE-2292) HTTPS / Native Management protocol mismatch when using SSL
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2292?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-2292:
-----------------------------------
I should not, the default standalone config works fine.
> 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/77158040d82d74af33800fce88... 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@2ab25536
> 11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel@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@1cc4241b
> This was with native management, but I see the same thing using https.
> 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)
9 years, 2 months
[JBoss JIRA] (WFCORE-2292) HTTPS / Native Management protocol mismatch when using SSL
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2292?page=com.atlassian.jira.plugi... ]
Ken Wills edited comment on WFCORE-2292 at 2/13/17 12:38 PM:
-------------------------------------------------------------
I should note, the default standalone config works fine.
was (Author: luck3y):
I should not, the default standalone config works fine.
> 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/77158040d82d74af33800fce88... 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@2ab25536
> 11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel@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@1cc4241b
> This was with native management, but I see the same thing using https.
> 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)
9 years, 2 months
[JBoss JIRA] (WFCORE-2292) HTTPS / Native Management protocol mismatch when using SSL
by Ken Wills (JIRA)
Ken Wills created WFCORE-2292:
---------------------------------
Summary: 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/77158040d82d74af33800fce88... 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@2ab25536
11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel@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@1cc4241b
This was with native management, but I see the same thing using https.
Relevant 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>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2292) HTTPS / Native Management protocol mismatch when using SSL
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2292?page=com.atlassian.jira.plugi... ]
Ken Wills updated WFCORE-2292:
------------------------------
Description:
It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce88... 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@2ab25536
11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel@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@1cc4241b
This was with native management, but I see the same thing using https.
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}
was:
It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce88... 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@2ab25536
11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel@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@1cc4241b
This was with native management, but I see the same thing using https.
Relevant 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>
> 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/77158040d82d74af33800fce88... 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@2ab25536
> 11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel@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@1cc4241b
> This was with native management, but I see the same thing using https.
> 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)
9 years, 2 months