[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:
---------------------------------
Component/s: Test Suite
(was: CLI)
> :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: Test Suite
> 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)
11 years, 11 months
[JBoss JIRA] (WFLY-3703) arq.container.domain.ManagementClient.readRootNode does not see servers on remote hosts
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3703?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov updated WFLY-3703:
---------------------------------
Summary: arq.container.domain.ManagementClient.readRootNode does not see servers on remote hosts (was: :read-resource(recursive=true) ignoring non-DC hosts)
> arq.container.domain.ManagementClient.readRootNode does not see servers on remote hosts
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3703
> URL: https://issues.jboss.org/browse/WFLY-3703
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite
> 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)
11 years, 11 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 reopened WFLY-3703:
----------------------------------
Arquillian does have a WildFly component, so will try to reopen here again.
> :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)
11 years, 11 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 reopened WFLY-3703:
----------------------------------
Reopening to assign to Arquillian
> :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)
11 years, 11 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 closed WFLY-3703.
--------------------------------
Resolution: Won't Fix
Closing, product reassign is impossible. A new issue will be created for Arquillian
> :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)
11 years, 11 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 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)
11 years, 11 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)
11 years, 11 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)
11 years, 11 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)
11 years, 11 months