[JBoss JIRA] (WFLY-3492) JSSE configuration in security domain wrongly acceptes empty parameters
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-3492?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky commented on WFLY-3492:
-----------------------------------------
I've created WFCORE-90 for the CLI to improve the parsing in this case. It's been merged now, so once wildfly switches to the core 1.0.0.Alpha6 the changes will be in effect. So, with the changes in parsing the request for the operation will look like this
[standalone@localhost:9990 /] echo-dmr /subsystem=security/security-domain=trust-domain/jsse=classic:add(keystore=>{password=1234test,url=/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks})
{
"address" => [
("subsystem" => "security"),
("security-domain" => "trust-domain"),
("jsse" => "classic")
],
"operation" => "add",
"keystore" => {
">{password" => "1234test",
"url" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks}"
}
}
and if you try to execute it, it will fail with the following error
[standalone@localhost:9990 /] /subsystem=security/security-domain=trust-domain/jsse=classic:add(keystore=>{password=1234test,url=/Users/kabir/sourcecontrol/wildfly/git/wildfly/security/subsystem/src/test/resources/clientcert.jks})
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0155: password may not be null",
"rolled-back" => true
}
which will happen on the server. It won't find the required password parameter. And it doesn't care of the presence of the parameters it doesn't expect like >{password.
> JSSE configuration in security domain wrongly acceptes empty parameters
> -----------------------------------------------------------------------
>
> Key: WFLY-3492
> URL: https://issues.jboss.org/browse/WFLY-3492
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Reporter: Chao Wang
> Assignee: Alexey Loubyansky
>
> Description from https://bugzilla.redhat.com/show_bug.cgi?id=1080069:
> {noformat}
> When adding a jsse configuration in security domain through CLI, it's not persisted correctly.
> Steps to reproduce:
> * Run CLI (./jboss-cli.sh -c) and use this commands to configure new security domain:
> /subsystem=security/security-domain=trust-domain:add
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore=>{password=1234test,url=/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> reload
> * check standalone.xml, where should be sth. like
> <security-domain name="trust-domain">
> <jsse truststore-password="1234test" truststore-url="/home/jcacek/projects/ocsp-check/build/trusted-clients.jks"/>
> </security-domain>
> But there is:
> <security-domain name="trust-domain">
> <jsse/>
> </security-domain>
> {noformat}
> {noformat}
> I had a mistake in the second command, it should be:
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore={password=>1234test,url=>/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> Then it works.
> Nevertheless it's probably still a bug, when the original command returns:
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1877:
---------------------------
Priority: Critical (was: Major)
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JGRP-1875) UNICAST3/UNICAST2: sync receiver table with sender table
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1875?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1875.
----------------------------
Resolution: Done
> UNICAST3/UNICAST2: sync receiver table with sender table
> --------------------------------------------------------
>
> Key: JGRP-1875
> URL: https://issues.jboss.org/browse/JGRP-1875
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}).
> To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g.
> * B needs to get the lowest and highest seqno sent from A
> * B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message)
> * B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}}
> * B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos
> * B creates an entry for A with the lowest and highest seqnos
> * B sends a {{SYNC-ACK}} to A
> * A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again
> * A and B now use the usual protocols to retransmit missing messages
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JGRP-1875) UNICAST3/UNICAST2: sync receiver table with sender table
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1875?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1875:
--------------------------------
I actually ended up implementing sending of {{ACK}} and {{SEND-FIRST-SEQNO}} msgs with timestamps and dropping msgs that are older than the last timestamp received from the receiver. The design is here: https://github.com/belaban/JGroups/blob/master/doc/design/UNICAST3-SYNC.txt.
> UNICAST3/UNICAST2: sync receiver table with sender table
> --------------------------------------------------------
>
> Key: JGRP-1875
> URL: https://issues.jboss.org/browse/JGRP-1875
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}).
> To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g.
> * B needs to get the lowest and highest seqno sent from A
> * B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message)
> * B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}}
> * B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos
> * B creates an entry for A with the lowest and highest seqnos
> * B sends a {{SYNC-ACK}} to A
> * A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again
> * A and B now use the usual protocols to retransmit missing messages
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JGRP-1875) UNICAST3/UNICAST2: sync receiver table with sender table
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1875?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1875 at 9/9/14 7:56 AM:
--------------------------------------------------------
Hmm, there's a problem when a new connection is established:
* A (conn-id=1) sends A1(first)-A10 to B
* B receives A:3 first. Since this isn't tagged as {{first}}, B sends a SYNC to A
* A hasn't seen that SYNC yet, so it changes its {{conn-id}} to 3
* B now receives A:1(first) and creates the connection with {{conn-id}} == 2
* B also receives the other messages and adds them to the connections recv-window
* Now B receives the {{SYNC-OK}} message with {{conn-id}} == 3
** B now removes the recv-window for A and creates a new one with {{conn-id}} == 3
This race between the first message and SYNC happens because we cannot guarantee that the first message from A is always received _first_ by B.
I'm starting to dislike this whole SYNC business: we're fixing an edge case that happens 0.001% of the time, but introduce a complexity that's not warranted !
So what are the alternatives ?
h5. Do nothing (status quo) / first message creates the recv-window
* With {{conn-close-timeout}} set to a reasonably large value, JGRP-1873 can almost never happen
* The first message creates the recv-window
** If we get some messages before the first, they're dropped on the ground, but as soon as the first message is received (or retransmitted), the recv-window is created. Not too bad, as the first message is usually a JOIN or JOIN-RSP, and only then does message traffic start
h5. Use SYNC altogether (replace first message above)
* This means that the first N messages would always get dropped until a SYNC and subsequent SYNC-OK have been received
** This would be completely new logic, replacing a proven algorithm
h5. Provide connection establishment a la TCP (SYN / SYN-ACK - ACK)
* Complex state model (including timeouts and dreaded states such as TIME-WAIT)
* Redundant if run over TCP as transport
* Blocking semantics: threads need to block until connection has been established
was (Author: belaban):
Hmm, there's a problem when a new connection is established:
* A (conn-id=1) sends A1(first)-A10 to B
* B receives A:3 first. Since this isn't tagged as {{first}}, B sends a SYNC to A
* A hasn't seen that SYNC yet, so it changes its {{conn-id}} to 3
* B now receives A:1(first) and creates the connection with {{conn-id}} == 2
* B also receives the other messages and adds them to the connections recv-window
* Now B receives the {{SYNC-OK}} message with {{conn-id}} == 3
** B now removes the recv-window for A and creates a new one with {{conn-id}} == 3
This race between the first message and SYNC happens because we cannot guarantee that the first message from A is always received _first_ by B.
I'm starting to dislike this whole SYNC business: we're fixing an edge case that happens 0.001% of the time, but introduce a complexity that's not warranted !
So what are the alternatives ?
h5. Do nothing (status quo) / first message creates the recv-window
* With {{conn-close-timeout}} set to a reasonably large value, JGRP-1873 can almost never happen
* The first message creates the recv-window
** If we get some messages before the first, they're dropped on the ground, but as soon as the first message is received (or retransmitted), the recv-window is created. Not too bad, as the first message is usually a JOIN or JOIN-RSP, and only then does message traffic start
h5. Use SYNC altogether (replace first message above)
* This means that the first N messages would always get dropped until a SYNC and subsequent SYNC-OK have been received
** This would be completely new logic, replacing a proven algorithm
h5. Provide connection establishment a la TCP (SYN / SYNC-ACK - ACK)
* Complex state model (including timeouts and dreaded states such as TIME-WAIT)
* Redundant if run over TCP as transport
* Blocking semantics: threads need to block until connection has been established
> UNICAST3/UNICAST2: sync receiver table with sender table
> --------------------------------------------------------
>
> Key: JGRP-1875
> URL: https://issues.jboss.org/browse/JGRP-1875
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}).
> To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g.
> * B needs to get the lowest and highest seqno sent from A
> * B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message)
> * B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}}
> * B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos
> * B creates an entry for A with the lowest and highest seqnos
> * B sends a {{SYNC-ACK}} to A
> * A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again
> * A and B now use the usual protocols to retransmit missing messages
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JGRP-1873) UNICAST2: unilateral connection close of receiver can lead to missing seqnos in sender
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1873?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1873:
--------------------------------
This issue was fixed on master in {{UNICAST3}} (JGRP-1875) by using timestamping, which discards delayed or out-of-sequence STABLE/ACK messages.
I'm not going to backport this to {{UNICAST2}} as the recommendation is to move to {{UNICAST3}} anyway.
> UNICAST2: unilateral connection close of receiver can lead to missing seqnos in sender
> --------------------------------------------------------------------------------------
>
> Key: JGRP-1873
> URL: https://issues.jboss.org/browse/JGRP-1873
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6
>
>
> In {{UNICAST2}}, if we have a connection between sender A and receiver B, and B closes the connection (but not A), then A can end up with missing messages in its send table.
> Example:
> * A sends messages to B
> * A has an entry for B in its send-table: {{B: 10|20}} (lowest sent=10, highest sent=20)
> * B has an entry for A in its recv-table: {{A: 10|20}} (lowest received=10, highest received=20)
> * B now gets a view that doesn't contain A and closes its connection to A
> ** This results in B's connection to A getting removed
> * A now sends message {{A::21}}
> * B doesn't find an entry in its recv-table for A and sends {{GET-FIRST-SEQNO}} to A
> * A receives the request and sends message {{A::11 first}} - {{A:21}} to B. These messages are sent unreliably, so they can get dropped. Let's assume (for this example) that some of them are dropped.
> * B does receive {{A::11 first}} and creates an entry for A in its recv-table: {{A: 11|21}} (next to be received is {{A:12}})
> * Now a spurious {{STABLE(A::15)}} message by B is received by A
> ** This can happen when B sent the {{STABLE}} message *before* its connection to A was removed, but the message was delayed, e.g. by garbage collection
> ** Note that the connection ID ({{conn-id}} is the same, so A will _not_ reject the {{STABLE}} message by B
> * A receives the {{STABLE}} message and purges elements up to 15, so its new entry for B is: {{B:: 15|21}}
> * When B asks A for retransmission of messages {{A::12}} - {{A:21}}, A can only retransmit messages 16-21, but *not* {{A::12}} - {{A:15}} !
> Depending on which messages from A (which it sent unreliably on reception of {{GET-FIRST-SEQNO}}) were received by B, there would be never-ending retransmission requests from B to A for all or some messages in {{A[12..15]}}, e.g.
> {noformat}
> WARN [org.jgroups.protocols.UNICAST2] A: (requester=B) message B::13 not found in
> retransmission table of B: [15 | 15 | 22] (X elements, Y missing)
> {noformat}
> h5. Reordering of STABLE messages
> In the worst case, as {{STABLE}} messages are not sent reliably and can therefore get dropped or reordered, if A gets another {{STABLE(10)}} message after the {{STABLE(15)}} message, the error message above would look like this:
> {noformat}
> WARN [org.jgroups.protocols.UNICAST2] A: (requester=B) message B::13 not found in
> retransmission table of B: [10 | 10 | 22] (X elements, Y missing)
> {noformat}
> Note that, with https://issues.jboss.org/browse/JGRP-1872 fixed, this cannot occur anymore.
> h5. Solution
> There's no real solution but to upgrade to {{UNICAST3}}: when {{UNICAST3}} receives a view, it doesn't _remove_ receive (and send) connections immediately, but merely marks them as _closed_. The connection will only be removed after {{conn_close_timeout}} ms. If B therefore gets further messages from A, it will simply mark the receive connection as _open_ and doesn't need to send a {{GET-FIRST-SEQNO}} message to A as it still has all of A's messages.
> We could think of a connection establishment and teardown protocol used by all of the unicast protocols, which establishes connections similar to TCP. Senders would block until a connection is established etc and new conn-ids would be created, plus the current send- and receive- seqnos would be exchanged. This could also be used as a second line of defense, to re-establish the connection when a sender doesn't find messages requested for retransmission by a receiver. As an alternative, we could create a new protocol which syncs a receive table with a sender, e.g. https://issues.jboss.org/browse/JGRP-1875.
> To mitigate the above issue, {{FD_ALL}} rather than {{FD}} should be used, so that members suspect each other more or less at the same time. This is not the case with FD, where multiple hung (or GC'ing) members take N * timeout time to suspect. With {{FD_ALL}}, chances are that A and B suspect each other and later, both establish a new connection.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JGRP-1873) UNICAST2: unilateral connection close of receiver can lead to missing seqnos in sender
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1873?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1873.
----------------------------
Fix Version/s: (was: 3.5.1)
Resolution: Done
> UNICAST2: unilateral connection close of receiver can lead to missing seqnos in sender
> --------------------------------------------------------------------------------------
>
> Key: JGRP-1873
> URL: https://issues.jboss.org/browse/JGRP-1873
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6
>
>
> In {{UNICAST2}}, if we have a connection between sender A and receiver B, and B closes the connection (but not A), then A can end up with missing messages in its send table.
> Example:
> * A sends messages to B
> * A has an entry for B in its send-table: {{B: 10|20}} (lowest sent=10, highest sent=20)
> * B has an entry for A in its recv-table: {{A: 10|20}} (lowest received=10, highest received=20)
> * B now gets a view that doesn't contain A and closes its connection to A
> ** This results in B's connection to A getting removed
> * A now sends message {{A::21}}
> * B doesn't find an entry in its recv-table for A and sends {{GET-FIRST-SEQNO}} to A
> * A receives the request and sends message {{A::11 first}} - {{A:21}} to B. These messages are sent unreliably, so they can get dropped. Let's assume (for this example) that some of them are dropped.
> * B does receive {{A::11 first}} and creates an entry for A in its recv-table: {{A: 11|21}} (next to be received is {{A:12}})
> * Now a spurious {{STABLE(A::15)}} message by B is received by A
> ** This can happen when B sent the {{STABLE}} message *before* its connection to A was removed, but the message was delayed, e.g. by garbage collection
> ** Note that the connection ID ({{conn-id}} is the same, so A will _not_ reject the {{STABLE}} message by B
> * A receives the {{STABLE}} message and purges elements up to 15, so its new entry for B is: {{B:: 15|21}}
> * When B asks A for retransmission of messages {{A::12}} - {{A:21}}, A can only retransmit messages 16-21, but *not* {{A::12}} - {{A:15}} !
> Depending on which messages from A (which it sent unreliably on reception of {{GET-FIRST-SEQNO}}) were received by B, there would be never-ending retransmission requests from B to A for all or some messages in {{A[12..15]}}, e.g.
> {noformat}
> WARN [org.jgroups.protocols.UNICAST2] A: (requester=B) message B::13 not found in
> retransmission table of B: [15 | 15 | 22] (X elements, Y missing)
> {noformat}
> h5. Reordering of STABLE messages
> In the worst case, as {{STABLE}} messages are not sent reliably and can therefore get dropped or reordered, if A gets another {{STABLE(10)}} message after the {{STABLE(15)}} message, the error message above would look like this:
> {noformat}
> WARN [org.jgroups.protocols.UNICAST2] A: (requester=B) message B::13 not found in
> retransmission table of B: [10 | 10 | 22] (X elements, Y missing)
> {noformat}
> Note that, with https://issues.jboss.org/browse/JGRP-1872 fixed, this cannot occur anymore.
> h5. Solution
> There's no real solution but to upgrade to {{UNICAST3}}: when {{UNICAST3}} receives a view, it doesn't _remove_ receive (and send) connections immediately, but merely marks them as _closed_. The connection will only be removed after {{conn_close_timeout}} ms. If B therefore gets further messages from A, it will simply mark the receive connection as _open_ and doesn't need to send a {{GET-FIRST-SEQNO}} message to A as it still has all of A's messages.
> We could think of a connection establishment and teardown protocol used by all of the unicast protocols, which establishes connections similar to TCP. Senders would block until a connection is established etc and new conn-ids would be created, plus the current send- and receive- seqnos would be exchanged. This could also be used as a second line of defense, to re-establish the connection when a sender doesn't find messages requested for retransmission by a receiver. As an alternative, we could create a new protocol which syncs a receive table with a sender, e.g. https://issues.jboss.org/browse/JGRP-1875.
> To mitigate the above issue, {{FD_ALL}} rather than {{FD}} should be used, so that members suspect each other more or less at the same time. This is not the case with FD, where multiple hung (or GC'ing) members take N * timeout time to suspect. With {{FD_ALL}}, chances are that A and B suspect each other and later, both establish a new connection.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3831) Securing EJB comunitication via SSL is failed
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3831?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-3831.
------------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Rejected
This is reading as a request for assistance rather than a confirmed bug - for help with issues such as this please use the discussion forums, Jira is for tracking actual bugs and feature requests .
I would suggest starting from http://wildfly.org/ to find your way to the forums.
> Securing EJB comunitication via SSL is failed
> ----------------------------------------------
>
> Key: WFLY-3831
> URL: https://issues.jboss.org/browse/WFLY-3831
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: Jonhny Jonhny
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.Beta1
>
>
> I added the SSL configuration for ApplicationRealm as the guide in Jboss document, but It's failed when trying connection to server (Note that if I remove SSL configuration, it can connect to server successfully)
> <management>
> <security-realms>
> <security-realm name="ManagementRealm">
> <authentication>
> <local default-user="$local"/>
> <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
> </authentication>
> </security-realm>
> <security-realm name="ApplicationRealm">
> <server-identities>
> <ssl>
> <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="ybxiang_keystore_password"/>
> </ssl>
> </server-identities>
> <authentication>
> <jaas name="ybxiang-forum-jaas-security-domain"/>
> </authentication>
> </security-realm>
> </security-realms>
> <management-interfaces>
> <native-interface security-realm="ManagementRealm">
> <socket-binding native="management-native"/>
> </native-interface>
> <http-interface security-realm="ManagementRealm">
> <socket-binding http="management-http"/>
> </http-interface>
> </management-interfaces>
> </management>
> Client log
> !ENTRY com 0 0 2014-09-09 15:52:05.124
> !MESSAGE (Timezone is ICT.) ;3556; com.model.connection.ServerLink logged : "could not connect:
> java.lang.RuntimeException: java.lang.RuntimeException: javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://172.41.211.111:4447]
> at com.RemoteJMXDispatcher.connectToJMS(RemoteJMXDispatcher.java:455)
> at com.RemoteJMXDispatcher.<init>(RemoteJMXDispatcher.java:295)
> at com.RemoteJMXDispatcher.<init>(RemoteJMXDispatcher.java:288)
> at com.model.connection.SecuredRemoteJMXDispatcher.<init>(SecuredRemoteJMXDispatcher.java:39)
> at com.model.connection.SecuredRemoteJMXDispatcher.create(SecuredRemoteJMXDispatcher.java:86)
> at com.model.connection.ServerLink.login(ServerLink.java:325)
> at com.login.ConnectToServerRunnable.run(ConnectToServerRunnable.java:60)
> at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
> Caused by: java.lang.RuntimeException: javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://192.168.95.111:4447]
> at com.JMSUtil.getRemoteConnectionFactory(JMSUtil.java:108)
> at com.JMSUtil.createRemoteConnection(JMSUtil.java:78)
> at com.RemoteJMXDispatcher.connectToJMS(RemoteJMXDispatcher.java:404)
> ... 7 more
> Caused by: javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://172.41.211.111:4447]
> at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.namingStore(HaRemoteNamingStore.java:144)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:125)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:241)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
> at javax.naming.InitialContext.lookup(InitialContext.java:411)
> at com.JMSUtil.getRemoteConnectionFactory(JMSUtil.java:101)
> ... 9 more"
>
>
> Server log
> 2014-09-09 15:59:42,758 ERROR [Remoting "config-based-naming-client-endpoint" read-1]-[org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL
> 2014-09-09 16:00:42,762 ERROR [Remoting "config-based-naming-client-endpoint" read-1]-[org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL
> 2014-09-09 16:01:42,766 ERROR [Remoting "config-based-naming-client-endpoint" read-1]-[org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL
> 2014-09-09 16:02:42,770 ERROR [Remoting "config-based-naming-client-endpoint" read-1]-[org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL
> 2014-09-09 16:03:42,773 ERROR [Remoting "config-based-naming-client-endpoint" read-1]-[org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL
> 2014-09-09 16:04:42,777 ERROR [Remoting "config-based-naming-client-endpoint" read-1]-[org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL
> 2014-09-09 16:05:42,781 ERROR [Remoting "config-based-naming-client-endpoint" read-1]-[org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3831) Securing EJB comunitication via SSL is failed
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3831?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-3831:
--------------------------------------
Assignee: Darran Lofthouse (was: David Lloyd)
> Securing EJB comunitication via SSL is failed
> ----------------------------------------------
>
> Key: WFLY-3831
> URL: https://issues.jboss.org/browse/WFLY-3831
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: Jonhny Jonhny
> Assignee: Darran Lofthouse
>
> I added the SSL configuration for ApplicationRealm as the guide in Jboss document, but It's failed when trying connection to server (Note that if I remove SSL configuration, it can connect to server successfully)
> <management>
> <security-realms>
> <security-realm name="ManagementRealm">
> <authentication>
> <local default-user="$local"/>
> <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
> </authentication>
> </security-realm>
> <security-realm name="ApplicationRealm">
> <server-identities>
> <ssl>
> <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="ybxiang_keystore_password"/>
> </ssl>
> </server-identities>
> <authentication>
> <jaas name="ybxiang-forum-jaas-security-domain"/>
> </authentication>
> </security-realm>
> </security-realms>
> <management-interfaces>
> <native-interface security-realm="ManagementRealm">
> <socket-binding native="management-native"/>
> </native-interface>
> <http-interface security-realm="ManagementRealm">
> <socket-binding http="management-http"/>
> </http-interface>
> </management-interfaces>
> </management>
> Client log
> !ENTRY com 0 0 2014-09-09 15:52:05.124
> !MESSAGE (Timezone is ICT.) ;3556; com.model.connection.ServerLink logged : "could not connect:
> java.lang.RuntimeException: java.lang.RuntimeException: javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://172.41.211.111:4447]
> at com.RemoteJMXDispatcher.connectToJMS(RemoteJMXDispatcher.java:455)
> at com.RemoteJMXDispatcher.<init>(RemoteJMXDispatcher.java:295)
> at com.RemoteJMXDispatcher.<init>(RemoteJMXDispatcher.java:288)
> at com.model.connection.SecuredRemoteJMXDispatcher.<init>(SecuredRemoteJMXDispatcher.java:39)
> at com.model.connection.SecuredRemoteJMXDispatcher.create(SecuredRemoteJMXDispatcher.java:86)
> at com.model.connection.ServerLink.login(ServerLink.java:325)
> at com.login.ConnectToServerRunnable.run(ConnectToServerRunnable.java:60)
> at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
> Caused by: java.lang.RuntimeException: javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://192.168.95.111:4447]
> at com.JMSUtil.getRemoteConnectionFactory(JMSUtil.java:108)
> at com.JMSUtil.createRemoteConnection(JMSUtil.java:78)
> at com.RemoteJMXDispatcher.connectToJMS(RemoteJMXDispatcher.java:404)
> ... 7 more
> Caused by: javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://172.41.211.111:4447]
> at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.namingStore(HaRemoteNamingStore.java:144)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:125)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:241)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
> at javax.naming.InitialContext.lookup(InitialContext.java:411)
> at com.JMSUtil.getRemoteConnectionFactory(JMSUtil.java:101)
> ... 9 more"
>
>
> Server log
> 2014-09-09 15:59:42,758 ERROR [Remoting "config-based-naming-client-endpoint" read-1]-[org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL
> 2014-09-09 16:00:42,762 ERROR [Remoting "config-based-naming-client-endpoint" read-1]-[org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL
> 2014-09-09 16:01:42,766 ERROR [Remoting "config-based-naming-client-endpoint" read-1]-[org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL
> 2014-09-09 16:02:42,770 ERROR [Remoting "config-based-naming-client-endpoint" read-1]-[org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL
> 2014-09-09 16:03:42,773 ERROR [Remoting "config-based-naming-client-endpoint" read-1]-[org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL
> 2014-09-09 16:04:42,777 ERROR [Remoting "config-based-naming-client-endpoint" read-1]-[org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL
> 2014-09-09 16:05:42,781 ERROR [Remoting "config-based-naming-client-endpoint" read-1]-[org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: Client starting STARTTLS but channel doesn't support SSL
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3266:
-----------------------------------------------
Panagiotis Sotiropoulos <psotirop(a)redhat.com> changed the Status of [bug 1088463|https://bugzilla.redhat.com/show_bug.cgi?id=1088463] from POST to ASSIGNED
> Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3266
> URL: https://issues.jboss.org/browse/WFLY-3266
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
>
> In case of large parameter input for EJB invocations the ejb-client throw the Exception below.
> The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found.
> java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.uploadData(Unknown Source)
> at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month