[JBoss JIRA] (WFLY-3703) :read-resource(recursive=true) ignoring non-DC hosts
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3703?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov closed WFLY-3703.
--------------------------------
Resolution: Won't Fix
False alarm. The issue is a bug in Arquillian remote adapter that doesn't use proxies=true while reading recursively.
> :read-resource(recursive=true) ignoring non-DC hosts
> ----------------------------------------------------
>
> Key: WFLY-3703
> URL: https://issues.jboss.org/browse/WFLY-3703
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Attachments: non-recursive.txt, recursive-runtime.txt, recursive.txt
>
>
> This issue comes from trying to use Arquillian against the cluster.
> The cluster is setup such that DC is on 127.0.0.1 and hosts no servers, Host1 is on 127.0.0.2 and hosts one server node1, Host2 is on 127.0.0.3 and hosts one server node2, etc.
> Arquillian uses :read-resource(recursive=true) to enumerate all the servers on all the hosts available.
> It fails because the CLI and API underlying it do not return ANY hosts other than master when polled recursively.
> This is always reproducible and easily reproduced via CLI by hand as well.
> {noformat}
> [arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > non-recursive.txt <<EOF
> :read-resource()
> EOF
> {noformat}
> contains, among other, output:
> {noformat}
> "host" => {
> "master" => undefined,
> "host3" => undefined,
> "host2" => undefined,
> "host1" => undefined
> },
> {noformat}
> while
> {noformat}
> [arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > recursive.txt <<EOF
> :read-resource(recursive=true)
> EOF
> {noformat}
> contains only
> {noformat}
> "host" => {"master" => {
> "directory-grouping" => "by-server",
> "domain-controller" => {"local" => {}},
> "management-major-version" => 2,
> "management-micro-version" => 0,
> "management-minor-version" => 1,
> <snip>
> {noformat}
> and no other entries for any other hosts.
> As a result domain-deploying Arquillian can only deploy to nodes that are located on the DC's host and never sees the nodes in any other topology.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFLY-3704) WebSocket Sessions must be manually closed
by Cody Lerum (JIRA)
[ https://issues.jboss.org/browse/WFLY-3704?page=com.atlassian.jira.plugin.... ]
Cody Lerum updated WFLY-3704:
-----------------------------
Description:
Currently if a WebSocket session goes inactive due to the browser shutting down or the user closing a tab the browser does not send a close event to the server. This behavior seems the same with Chrome and IE.
The underlying TCP socket is however inactive and can be confirmed by calling a Session#isOpen which returns false. This will cause a build up of sessions unless the user does something like
{code}
for (Session session : sessions) {
if (!session.isOpen()) {
session.close();
}
}
{code}
This would need to be done periodically by the application. Shouldn't the server automatically close these sessions when the underlying socket goes inactive?
was:
Currently if a Web Socket session goes inactive due to the browser shutting down or the user closing a tab the browser does not send a close event to the server. This behavior seems the same with Chrome and IE.
The underlying TCP socket is however inactive and can be confirmed by calling a Session#isOpen which returns false. This will cause a build up of sessions unless the user does something like
{code}
for (Session session : sessions) {
if (!session.isOpen()) {
session.close();
}
}
{code}
This would need to be done periodically by the application. Shouldn't the server automatically close these sessions when the underlying socket goes inactive?
> WebSocket Sessions must be manually closed
> ------------------------------------------
>
> Key: WFLY-3704
> URL: https://issues.jboss.org/browse/WFLY-3704
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 8.1.0.Final
> Reporter: Cody Lerum
> Assignee: Jason Greene
> Labels: websockets
>
> Currently if a WebSocket session goes inactive due to the browser shutting down or the user closing a tab the browser does not send a close event to the server. This behavior seems the same with Chrome and IE.
> The underlying TCP socket is however inactive and can be confirmed by calling a Session#isOpen which returns false. This will cause a build up of sessions unless the user does something like
> {code}
> for (Session session : sessions) {
> if (!session.isOpen()) {
> session.close();
> }
> }
> {code}
> This would need to be done periodically by the application. Shouldn't the server automatically close these sessions when the underlying socket goes inactive?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFCORE-41) Update slf4j-api to 1.7.7
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-41?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFCORE-41:
--------------------------------
Summary: Update slf4j-api to 1.7.7 (was: Update slf4j-api to 1.7.5)
> Update slf4j-api to 1.7.7
> -------------------------
>
> Key: WFCORE-41
> URL: https://issues.jboss.org/browse/WFCORE-41
> Project: WildFly Core
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: Jorge Solorzano
> Assignee: James Perkins
> Labels: slf4j
>
> The logger factories in most SLF4J modules namely in jcl-over-slf4j, log4j-over-slf4j, slf4j-jcl, slf4j-jdk14, slf4j-log4j12, and slf4j-simple now use a ConcurrentHashMap instead of a regular HashMap to cache logger instances. This change significantly improves logger retrieval times at the cost of some memory overhead.
> Acording to SLF4J developers:
> Given the significance of these performance improvements, users are highly encouraged to migrate to SLF4J version 1.7.5 or later.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFLY-3704) WebSocket Sessions must be manually closed
by Cody Lerum (JIRA)
Cody Lerum created WFLY-3704:
--------------------------------
Summary: WebSocket Sessions must be manually closed
Key: WFLY-3704
URL: https://issues.jboss.org/browse/WFLY-3704
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 8.1.0.Final
Reporter: Cody Lerum
Assignee: Jason Greene
Currently if a Web Socket session goes inactive due to the browser shutting down or the user closing a tab the browser does not send a close event to the server. This behavior seems the same with Chrome and IE.
The underlying TCP socket is however inactive and can be confirmed by calling a Session#isOpen which returns false. This will cause a build up of sessions unless the user does something like
{code}
for (Session session : sessions) {
if (!session.isOpen()) {
session.close();
}
}
{code}
This would need to be done periodically by the application. Shouldn't the server automatically close these sessions when the underlying socket goes inactive?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFLY-3703) :read-resource(recursive=true) ignoring non-DC hosts
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3703?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov updated WFLY-3703:
---------------------------------
Attachment: recursive-runtime.txt
Attached output with recursive=true,include-runtime=true as well - same results.
> :read-resource(recursive=true) ignoring non-DC hosts
> ----------------------------------------------------
>
> Key: WFLY-3703
> URL: https://issues.jboss.org/browse/WFLY-3703
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Attachments: non-recursive.txt, recursive-runtime.txt, recursive.txt
>
>
> This issue comes from trying to use Arquillian against the cluster.
> The cluster is setup such that DC is on 127.0.0.1 and hosts no servers, Host1 is on 127.0.0.2 and hosts one server node1, Host2 is on 127.0.0.3 and hosts one server node2, etc.
> Arquillian uses :read-resource(recursive=true) to enumerate all the servers on all the hosts available.
> It fails because the CLI and API underlying it do not return ANY hosts other than master when polled recursively.
> This is always reproducible and easily reproduced via CLI by hand as well.
> {noformat}
> [arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > non-recursive.txt <<EOF
> :read-resource()
> EOF
> {noformat}
> contains, among other, output:
> {noformat}
> "host" => {
> "master" => undefined,
> "host3" => undefined,
> "host2" => undefined,
> "host1" => undefined
> },
> {noformat}
> while
> {noformat}
> [arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > recursive.txt <<EOF
> :read-resource(recursive=true)
> EOF
> {noformat}
> contains only
> {noformat}
> "host" => {"master" => {
> "directory-grouping" => "by-server",
> "domain-controller" => {"local" => {}},
> "management-major-version" => 2,
> "management-micro-version" => 0,
> "management-minor-version" => 1,
> <snip>
> {noformat}
> and no other entries for any other hosts.
> As a result domain-deploying Arquillian can only deploy to nodes that are located on the DC's host and never sees the nodes in any other topology.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFLY-3703) :read-resource(recursive=true) ignoring non-DC hosts
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3703?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov updated WFLY-3703:
---------------------------------
Description:
This issue comes from trying to use Arquillian against the cluster.
The cluster is setup such that DC is on 127.0.0.1 and hosts no servers, Host1 is on 127.0.0.2 and hosts one server node1, Host2 is on 127.0.0.3 and hosts one server node2, etc.
Arquillian uses :read-resource(recursive=true) to enumerate all the servers on all the hosts available.
It fails because the CLI and API underlying it do not return ANY hosts other than master when polled recursively.
This is always reproducible and easily reproduced via CLI by hand as well.
{noformat}
[arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > non-recursive.txt <<EOF
:read-resource()
EOF
{noformat}
contains, among other, output:
{noformat}
"host" => {
"master" => undefined,
"host3" => undefined,
"host2" => undefined,
"host1" => undefined
},
{noformat}
while
{noformat}
[arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > recursive.txt <<EOF
:read-resource(recursive=true)
EOF
{noformat}
contains only
{noformat}
"host" => {"master" => {
"directory-grouping" => "by-server",
"domain-controller" => {"local" => {}},
"management-major-version" => 2,
"management-micro-version" => 0,
"management-minor-version" => 1,
<snip>
{noformat}
and no other entries for any other hosts.
As a result domain-deploying Arquillian can only deploy to nodes that are located on the DC's host and never sees the nodes in any other topology.
was:
This issue comes from trying to use Arquillian against the cluster.
The cluster is setup such that DC is on 127.0.0.1 and hosts no servers, Host1 is on 127.0.0.2 and hosts one server node1, Host2 is on 127.0.0.3 and hosts one server node2, etc.
Arquillian uses :read-resource(recursive=true) to enumerate all the servers on all the hosts available.
It fails because the CLI and API underlying it do not return ANY hosts other than master when polled recursively.
This is always reproducible and easily reproduced via CLI by hand as well.
{noformat}
[arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > non-recursive.txt <<EOF
:read-resource()
EOF
{noformat}
contains, among other, output:
{noformat}
"host" => {
"master" => undefined,
"host3" => undefined,
"host2" => undefined,
"host1" => undefined
},
[arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > recursive.txt <<EOF
:read-resource(recursive=true)
EOF
{noformat}
contains only
{noformat}
"host" => {"master" => {
"directory-grouping" => "by-server",
"domain-controller" => {"local" => {}},
"management-major-version" => 2,
"management-micro-version" => 0,
"management-minor-version" => 1,
<snip>
{noformat}
and no other entries for any other hosts.
As a result domain-deploying Arquillian can only deploy to nodes that are located on the DC's host and never sees the nodes in any other topology.
> :read-resource(recursive=true) ignoring non-DC hosts
> ----------------------------------------------------
>
> Key: WFLY-3703
> URL: https://issues.jboss.org/browse/WFLY-3703
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Attachments: non-recursive.txt, recursive.txt
>
>
> This issue comes from trying to use Arquillian against the cluster.
> The cluster is setup such that DC is on 127.0.0.1 and hosts no servers, Host1 is on 127.0.0.2 and hosts one server node1, Host2 is on 127.0.0.3 and hosts one server node2, etc.
> Arquillian uses :read-resource(recursive=true) to enumerate all the servers on all the hosts available.
> It fails because the CLI and API underlying it do not return ANY hosts other than master when polled recursively.
> This is always reproducible and easily reproduced via CLI by hand as well.
> {noformat}
> [arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > non-recursive.txt <<EOF
> :read-resource()
> EOF
> {noformat}
> contains, among other, output:
> {noformat}
> "host" => {
> "master" => undefined,
> "host3" => undefined,
> "host2" => undefined,
> "host1" => undefined
> },
> {noformat}
> while
> {noformat}
> [arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > recursive.txt <<EOF
> :read-resource(recursive=true)
> EOF
> {noformat}
> contains only
> {noformat}
> "host" => {"master" => {
> "directory-grouping" => "by-server",
> "domain-controller" => {"local" => {}},
> "management-major-version" => 2,
> "management-micro-version" => 0,
> "management-minor-version" => 1,
> <snip>
> {noformat}
> and no other entries for any other hosts.
> As a result domain-deploying Arquillian can only deploy to nodes that are located on the DC's host and never sees the nodes in any other topology.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFLY-3703) :read-resource(recursive=true) ignoring non-DC hosts
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3703?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov updated WFLY-3703:
---------------------------------
Description:
This issue comes from trying to use Arquillian against the cluster.
The cluster is setup such that DC is on 127.0.0.1 and hosts no servers, Host1 is on 127.0.0.2 and hosts one server node1, Host2 is on 127.0.0.3 and hosts one server node2, etc.
Arquillian uses :read-resource(recursive=true) to enumerate all the servers on all the hosts available.
It fails because the CLI and API underlying it do not return ANY hosts other than master when polled recursively.
This is always reproducible and easily reproduced via CLI by hand as well.
{noformat}
[arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > non-recursive.txt <<EOF
:read-resource()
EOF
{noformat}
contains, among other, output:
{noformat}
"host" => {
"master" => undefined,
"host3" => undefined,
"host2" => undefined,
"host1" => undefined
},
[arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > recursive.txt <<EOF
:read-resource(recursive=true)
EOF
{noformat}
contains only
{noformat}
"host" => {"master" => {
"directory-grouping" => "by-server",
"domain-controller" => {"local" => {}},
"management-major-version" => 2,
"management-micro-version" => 0,
"management-minor-version" => 1,
<snip>
{noformat}
and no other entries for any other hosts.
As a result domain-deploying Arquillian can only deploy to nodes that are located on the DC's host and never sees the nodes in any other topology.
was:
This issue comes from trying to use Arquillian against the cluster.
The cluster is setup such that DC is on 127.0.0.1 and hosts no servers, Host1 is on 127.0.0.2 and hosts one server node1, Host2 is on 127.0.0.3 and hosts one server node2, etc.
Arquillian uses :read-resource(recursive=true) to enumerate all the servers on all the hosts available.
It fails because the CLI and API underlying it do not return ANY hosts other than master when polled recursively.
This is always reproducible and easily reproduced via CLI by hand as well.
[arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > non-recursive.txt <<EOF
:read-resource()
EOF
contains, among other, output:
"host" => {
"master" => undefined,
"host3" => undefined,
"host2" => undefined,
"host1" => undefined
},
[arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > recursive.txt <<EOF
:read-resource(recursive=true)
EOF
contains only
"host" => {"master" => {
"directory-grouping" => "by-server",
"domain-controller" => {"local" => {}},
"management-major-version" => 2,
"management-micro-version" => 0,
"management-minor-version" => 1,
<snip>
and no other entries for any other hosts.
As a result domain-deploying Arquillian can only deploy to nodes that are located on the DC's host and never sees the nodes in any other topology.
> :read-resource(recursive=true) ignoring non-DC hosts
> ----------------------------------------------------
>
> Key: WFLY-3703
> URL: https://issues.jboss.org/browse/WFLY-3703
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Attachments: non-recursive.txt, recursive.txt
>
>
> This issue comes from trying to use Arquillian against the cluster.
> The cluster is setup such that DC is on 127.0.0.1 and hosts no servers, Host1 is on 127.0.0.2 and hosts one server node1, Host2 is on 127.0.0.3 and hosts one server node2, etc.
> Arquillian uses :read-resource(recursive=true) to enumerate all the servers on all the hosts available.
> It fails because the CLI and API underlying it do not return ANY hosts other than master when polled recursively.
> This is always reproducible and easily reproduced via CLI by hand as well.
> {noformat}
> [arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > non-recursive.txt <<EOF
> :read-resource()
> EOF
> {noformat}
> contains, among other, output:
> {noformat}
> "host" => {
> "master" => undefined,
> "host3" => undefined,
> "host2" => undefined,
> "host1" => undefined
> },
> [arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > recursive.txt <<EOF
> :read-resource(recursive=true)
> EOF
> {noformat}
> contains only
> {noformat}
> "host" => {"master" => {
> "directory-grouping" => "by-server",
> "domain-controller" => {"local" => {}},
> "management-major-version" => 2,
> "management-micro-version" => 0,
> "management-minor-version" => 1,
> <snip>
> {noformat}
> and no other entries for any other hosts.
> As a result domain-deploying Arquillian can only deploy to nodes that are located on the DC's host and never sees the nodes in any other topology.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFLY-3703) :read-resource(recursive=true) ignoring non-DC hosts
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3703?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov updated WFLY-3703:
---------------------------------
Description:
This issue comes from trying to use Arquillian against the cluster.
The cluster is setup such that DC is on 127.0.0.1 and hosts no servers, Host1 is on 127.0.0.2 and hosts one server node1, Host2 is on 127.0.0.3 and hosts one server node2, etc.
Arquillian uses :read-resource(recursive=true) to enumerate all the servers on all the hosts available.
It fails because the CLI and API underlying it do not return ANY hosts other than master when polled recursively.
This is always reproducible and easily reproduced via CLI by hand as well.
[arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > non-recursive.txt <<EOF
:read-resource()
EOF
contains, among other, output:
"host" => {
"master" => undefined,
"host3" => undefined,
"host2" => undefined,
"host1" => undefined
},
[arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > recursive.txt <<EOF
:read-resource(recursive=true)
EOF
contains only
"host" => {"master" => {
"directory-grouping" => "by-server",
"domain-controller" => {"local" => {}},
"management-major-version" => 2,
"management-micro-version" => 0,
"management-minor-version" => 1,
<snip>
and no other entries for any other hosts.
As a result domain-deploying Arquillian can only deploy to nodes that are located on the DC's host and never sees the nodes in any other topology.
was:
This issues comes from trying to use Arquillian against the cluster.
The cluster is setup such that DC is on 127.0.0.1 and hosts no servers, Host1 is on 127.0.0.2 and hosts one server node1, Host2 is on 127.0.0.3 and hosts one server node2, etc.
Arquillian uses :read-resource(recursive=true) to enumerate all the servers on all the hosts available.
It fails because the CLI and API underlying it do not return ANY hosts other than master when polled recursively.
This is always reproducible and easily reproduced via CLI by hand as well.
[arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > non-recursive.txt <<EOF
:read-resource()
EOF
contains output among others:
"host" => {
"master" => undefined,
"host3" => undefined,
"host2" => undefined,
"host1" => undefined
},
[arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > recursive.txt <<EOF
:read-resource(recursive=true)
EOF
contains only
"host" => {"master" => {
"directory-grouping" => "by-server",
"domain-controller" => {"local" => {}},
"management-major-version" => 2,
"management-micro-version" => 0,
"management-minor-version" => 1,
<snip>
and no other entries for any other hosts.
As a result domain-deploying Arquillian can only deploy to nodes that are located on the DC's host and never sees the nodes in any other topology.
> :read-resource(recursive=true) ignoring non-DC hosts
> ----------------------------------------------------
>
> Key: WFLY-3703
> URL: https://issues.jboss.org/browse/WFLY-3703
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Attachments: non-recursive.txt, recursive.txt
>
>
> This issue comes from trying to use Arquillian against the cluster.
> The cluster is setup such that DC is on 127.0.0.1 and hosts no servers, Host1 is on 127.0.0.2 and hosts one server node1, Host2 is on 127.0.0.3 and hosts one server node2, etc.
> Arquillian uses :read-resource(recursive=true) to enumerate all the servers on all the hosts available.
> It fails because the CLI and API underlying it do not return ANY hosts other than master when polled recursively.
> This is always reproducible and easily reproduced via CLI by hand as well.
> [arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > non-recursive.txt <<EOF
> :read-resource()
> EOF
> contains, among other, output:
> "host" => {
> "master" => undefined,
> "host3" => undefined,
> "host2" => undefined,
> "host1" => undefined
> },
> [arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > recursive.txt <<EOF
> :read-resource(recursive=true)
> EOF
> contains only
> "host" => {"master" => {
> "directory-grouping" => "by-server",
> "domain-controller" => {"local" => {}},
> "management-major-version" => 2,
> "management-micro-version" => 0,
> "management-minor-version" => 1,
> <snip>
> and no other entries for any other hosts.
> As a result domain-deploying Arquillian can only deploy to nodes that are located on the DC's host and never sees the nodes in any other topology.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFLY-3703) :read-resource(recursive=true) ignoring non-DC hosts
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3703?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov updated WFLY-3703:
---------------------------------
Attachment: recursive.txt
non-recursive.txt
Recursive and non-recursive output for the same domain
> :read-resource(recursive=true) ignoring non-DC hosts
> ----------------------------------------------------
>
> Key: WFLY-3703
> URL: https://issues.jboss.org/browse/WFLY-3703
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Attachments: non-recursive.txt, recursive.txt
>
>
> This issues comes from trying to use Arquillian against the cluster.
> The cluster is setup such that DC is on 127.0.0.1 and hosts no servers, Host1 is on 127.0.0.2 and hosts one server node1, Host2 is on 127.0.0.3 and hosts one server node2, etc.
> Arquillian uses :read-resource(recursive=true) to enumerate all the servers on all the hosts available.
> It fails because the CLI and API underlying it do not return ANY hosts other than master when polled recursively.
> This is always reproducible and easily reproduced via CLI by hand as well.
> [arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > non-recursive.txt <<EOF
> :read-resource()
> EOF
> contains output among others:
> "host" => {
> "master" => undefined,
> "host3" => undefined,
> "host2" => undefined,
> "host1" => undefined
> },
> [arcivanov@aimobile-sm bin]$ ./jboss-cli.sh -c > recursive.txt <<EOF
> :read-resource(recursive=true)
> EOF
> contains only
> "host" => {"master" => {
> "directory-grouping" => "by-server",
> "domain-controller" => {"local" => {}},
> "management-major-version" => 2,
> "management-micro-version" => 0,
> "management-minor-version" => 1,
> <snip>
> and no other entries for any other hosts.
> As a result domain-deploying Arquillian can only deploy to nodes that are located on the DC's host and never sees the nodes in any other topology.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months