[JBoss JIRA] (WFLY-12224) CLI output is doubled after embed-server reload
by Ondrej Kotek (Jira)
Ondrej Kotek created WFLY-12224:
-----------------------------------
Summary: CLI output is doubled after embed-server reload
Key: WFLY-12224
URL: https://issues.jboss.org/browse/WFLY-12224
Project: WildFly
Issue Type: Bug
Components: CLI
Affects Versions: 18.0.0.Beta1
Reporter: Ondrej Kotek
Assignee: Jean Francois Denise
CLI output is doubled after embed-server reload:
{noformat}
[okotek@localhost wildfly-18.0.0.Beta1-SNAPSHOT]$ ./bin/jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] embed-server
[standalone@embedded /] :whoami
{
"outcome" => "success",
"result" => {"identity" => {"username" => "anonymous"}}
}
[standalone@embedded /] reload
[standalone@embedded /] :whoami
12:34:27,735 INFO [org.jboss.as.cli.CommandContext] (CLI command) {
"outcome" => "success",
"result" => {"identity" => {"username" => "anonymous"}}
}
{
"outcome" => "success",
"result" => {"identity" => {"username" => "anonymous"}}
}
{noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12222) Clustering subsystems integration with WildFly Discovery SPI (tracker Jira)
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-12222?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-12222:
----------------------------------
Description:
Ultimately, we could employ WildFly Discovery SPI to handle services discovery in a generic way. However, since the subsystem currently only supplies one provider based on static discovery, its usefulness is limited. To untangle the chicken-egg problem, we could first integrate the clustering subsystems with the discovery SPI,
# JGroups discovery
# remote-cache-container remote servers
# mod_cluster
then supply discovery providers,
# static list (implemented)
# multicast-based
# k8s-based (replacing JGroups' OPENSHIFT_PING, DNS_PING, KUBE_PING, etc)
# cloud providers specific (replacing S3_PING, NATIVE_S3_PING, AZURE_PING, GOOGLE_PING, etc)
This requires fixes to the discovery subsystem such as
# ability to register new providers
# changing static providers should require server reload
# etc
was:Ultimately,
> Clustering subsystems integration with WildFly Discovery SPI (tracker Jira)
> ---------------------------------------------------------------------------
>
> Key: WFLY-12222
> URL: https://issues.jboss.org/browse/WFLY-12222
> Project: WildFly
> Issue Type: Task
> Components: Clustering, mod_cluster
> Affects Versions: 17.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
>
> Ultimately, we could employ WildFly Discovery SPI to handle services discovery in a generic way. However, since the subsystem currently only supplies one provider based on static discovery, its usefulness is limited. To untangle the chicken-egg problem, we could first integrate the clustering subsystems with the discovery SPI,
> # JGroups discovery
> # remote-cache-container remote servers
> # mod_cluster
> then supply discovery providers,
> # static list (implemented)
> # multicast-based
> # k8s-based (replacing JGroups' OPENSHIFT_PING, DNS_PING, KUBE_PING, etc)
> # cloud providers specific (replacing S3_PING, NATIVE_S3_PING, AZURE_PING, GOOGLE_PING, etc)
> This requires fixes to the discovery subsystem such as
> # ability to register new providers
> # changing static providers should require server reload
> # etc
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12222) Clustering subsystems integration with WildFly Discovery SPI (tracker Jira)
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-12222?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-12222:
----------------------------------
Description:
Ultimately, we could employ WildFly Discovery SPI to handle services discovery in a generic way. However, since the subsystem currently only supplies one provider based on static discovery, its usefulness is limited. To untangle the chicken-egg problem, we could first integrate the clustering subsystems with the discovery SPI,
* JGroups discovery
* remote-cache-container remote servers
* mod_cluster
then supply discovery providers,
* static list (implemented)
* multicast-based
* k8s-based (replacing JGroups' OPENSHIFT_PING, DNS_PING, KUBE_PING, etc)
* cloud providers specific (replacing S3_PING, NATIVE_S3_PING, AZURE_PING, GOOGLE_PING, etc)
This requires fixes to the discovery subsystem such as
* ability to register new providers
* changing static providers should require server reload
* TBD
was:
Ultimately, we could employ WildFly Discovery SPI to handle services discovery in a generic way. However, since the subsystem currently only supplies one provider based on static discovery, its usefulness is limited. To untangle the chicken-egg problem, we could first integrate the clustering subsystems with the discovery SPI,
# JGroups discovery
# remote-cache-container remote servers
# mod_cluster
then supply discovery providers,
# static list (implemented)
# multicast-based
# k8s-based (replacing JGroups' OPENSHIFT_PING, DNS_PING, KUBE_PING, etc)
# cloud providers specific (replacing S3_PING, NATIVE_S3_PING, AZURE_PING, GOOGLE_PING, etc)
This requires fixes to the discovery subsystem such as
# ability to register new providers
# changing static providers should require server reload
# etc
> Clustering subsystems integration with WildFly Discovery SPI (tracker Jira)
> ---------------------------------------------------------------------------
>
> Key: WFLY-12222
> URL: https://issues.jboss.org/browse/WFLY-12222
> Project: WildFly
> Issue Type: Task
> Components: Clustering, mod_cluster
> Affects Versions: 17.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
>
> Ultimately, we could employ WildFly Discovery SPI to handle services discovery in a generic way. However, since the subsystem currently only supplies one provider based on static discovery, its usefulness is limited. To untangle the chicken-egg problem, we could first integrate the clustering subsystems with the discovery SPI,
> * JGroups discovery
> * remote-cache-container remote servers
> * mod_cluster
> then supply discovery providers,
> * static list (implemented)
> * multicast-based
> * k8s-based (replacing JGroups' OPENSHIFT_PING, DNS_PING, KUBE_PING, etc)
> * cloud providers specific (replacing S3_PING, NATIVE_S3_PING, AZURE_PING, GOOGLE_PING, etc)
> This requires fixes to the discovery subsystem such as
> * ability to register new providers
> * changing static providers should require server reload
> * TBD
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months