June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1614) Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts)

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1614?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1614: ---------------------------------------------- I have resync the PR with this additional fix. > Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts) > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-1614 > URL: https://issues.jboss.org/browse/WFCORE-1614 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Alpha3 > > Attachments: test.cli > > > We are proposing here to add a Cli option (command line option and an XML element) to make the CLI to echo the command and its options in non interactive mode. This will help to match a given command and its output. > For example, the "ls -l" command output would be: > [standalone@localhost:9990 /] ls -l > ATTRIBUTE VALUE TYPE > launch-type STANDALONE STRING > management-major-version 5 INT > management-micro-version 0 INT > management-minor-version 0 INT > ... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6778) Each Undertow server should expose a distinct SessionIdentifierCodec

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6778?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6778: ------------------------------- Description: Undertow exposes a single instance-id for the whole subsystem. This id is used by a load balancer to uniquely identify the node among other nodes in the load balancing group. However, this granularity is not correct. Undertow can define multiple servers, each with a unique set of listeners. From the perspective of the load balancer, these servers are distinct and thus must use distinct names. Thus, rather than installing a single SessionIdentifierCodec for the subsystem, we should install one instance per server. was: Currently, Undertow only exposes a single instance-id for the whole subsystem. This id is used by a load balancer to uniquely identify the node among other nodes in the load balancing group. However, this granularity is not correct. Undertow can define multiple servers, each with a unique set of listeners. From the perspective of the load balancer, these servers are distinct and thus must use distinct names. > Each Undertow server should expose a distinct SessionIdentifierCodec > -------------------------------------------------------------------- > > Key: WFLY-6778 > URL: https://issues.jboss.org/browse/WFLY-6778 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Undertow exposes a single instance-id for the whole subsystem. This id is used by a load balancer to uniquely identify the node among other nodes in the load balancing group. However, this granularity is not correct. > Undertow can define multiple servers, each with a unique set of listeners. From the perspective of the load balancer, these servers are distinct and thus must use distinct names. Thus, rather than installing a single SessionIdentifierCodec for the subsystem, we should install one instance per server. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6778) Each Undertow server should expose a distinct SessionIdentifierCodec

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6778?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6778: ------------------------------- Summary: Each Undertow server should expose a distinct SessionIdentifierCodec (was: Each Undertow server should expose a unique instance-id) > Each Undertow server should expose a distinct SessionIdentifierCodec > -------------------------------------------------------------------- > > Key: WFLY-6778 > URL: https://issues.jboss.org/browse/WFLY-6778 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Currently, Undertow only exposes a single instance-id for the whole subsystem. This id is used by a load balancer to uniquely identify the node among other nodes in the load balancing group. However, this granularity is not correct. > Undertow can define multiple servers, each with a unique set of listeners. From the perspective of the load balancer, these servers are distinct and thus must use distinct names. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6778) Each Undertow server should expose a unique instance-id

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6778?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-6778: ------------------------------------ @ctomc The fundamental problem is that we only install a single SessionIdentifierCodec for the subsystem, rather than a distinct SessionIdentifierCodec per server. I'll update the description to clarify. > Each Undertow server should expose a unique instance-id > ------------------------------------------------------- > > Key: WFLY-6778 > URL: https://issues.jboss.org/browse/WFLY-6778 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Currently, Undertow only exposes a single instance-id for the whole subsystem. This id is used by a load balancer to uniquely identify the node among other nodes in the load balancing group. However, this granularity is not correct. > Undertow can define multiple servers, each with a unique set of listeners. From the perspective of the load balancer, these servers are distinct and thus must use distinct names. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6779) Add WISE for Web console access

by R Searls (JIRA)

R Searls created WFLY-6779: ------------------------------ Summary: Add WISE for Web console access Key: WFLY-6779 URL: https://issues.jboss.org/browse/WFLY-6779 Project: WildFly Issue Type: Feature Request Components: Web Console Reporter: R Searls Assignee: R Searls Priority: Minor Wise is a Java framework for easily invoking webservices, which can be used as base for zero-code webservice invocation applications. (see http://wise.jboss.org/) Based upon Brian Stansberry's advise WISE is added to wfly using the "Mixed-Approach" for adding a feature. Once this is available in wfly. HAL can provide a link to it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6778) Each Undertow server should expose a unique instance-id

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6778?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-6778: ----------------------------------- distinct name would be combination of instance-id & server name. > Each Undertow server should expose a unique instance-id > ------------------------------------------------------- > > Key: WFLY-6778 > URL: https://issues.jboss.org/browse/WFLY-6778 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Currently, Undertow only exposes a single instance-id for the whole subsystem. This id is used by a load balancer to uniquely identify the node among other nodes in the load balancing group. However, this granularity is not correct. > Undertow can define multiple servers, each with a unique set of listeners. From the perspective of the load balancer, these servers are distinct and thus must use distinct names. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6778) Each Undertow server should expose a unique instance-id

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-6778: ---------------------------------- Summary: Each Undertow server should expose a unique instance-id Key: WFLY-6778 URL: https://issues.jboss.org/browse/WFLY-6778 Project: WildFly Issue Type: Bug Components: Clustering, Web (Undertow) Affects Versions: 10.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Currently, Undertow only exposes a single instance-id for the whole subsystem. This id is used by a load balancer to uniquely identify the node among other nodes in the load balancing group. However, this granularity is not correct. Undertow can define multiple servers, each with a unique set of listeners. From the perspective of the load balancer, these servers are distinct and thus must use distinct names. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1325) Wrong condition when parsing ironjacamar.rollback_on_fatal_error property

by Martin Simka (JIRA)

Martin Simka created JBJCA-1325: ----------------------------------- Summary: Wrong condition when parsing ironjacamar.rollback_on_fatal_error property Key: JBJCA-1325 URL: https://issues.jboss.org/browse/JBJCA-1325 Project: IronJacamar Issue Type: Bug Affects Versions: WildFly/IronJacamar 1.3.4.Final Reporter: Martin Simka Assignee: Stefano Maestri There is wrong condition in https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or... {code:java} value = SecurityActions.getSystemProperty("ironjacamar.rollback_on_fatal_error"); if (value != null && !value.trim().equals("")) { if ("true".equalsIgnoreCase(value) || "false".equalsIgnoreCase(value)) { doSetRollbackOnly = Boolean.parseBoolean(value); } else { StringTokenizer st = new StringTokenizer(value, ","); while (doDelistResource && st.hasMoreTokens()) // <-- should be while (doSetRollbackOnly ... { if (getPool().getName().equals(st.nextToken())) doSetRollbackOnly = false; } } } {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6777) Upgrade to OpenJPA impl compatible with JDK9

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-6777: --------------------------------- Summary: Upgrade to OpenJPA impl compatible with JDK9 Key: WFLY-6777 URL: https://issues.jboss.org/browse/WFLY-6777 Project: WildFly Issue Type: Sub-task Components: JPA / Hibernate Reporter: Tomaz Cerar Assignee: Scott Marlow Priority: Minor OpenJPA tests currently hang our testsuite as serp bytecode enhancer that OpenJPA uses hangs the deployment. For now test is not run on JDK9, but this should be re-enabled once there is release of openjpa that works fine with jdk9 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6762) Wildfly cluster failover test not working as expected on windows OS, when network is disabled on a VM(Node) or by shutting down the VM (Node).

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6762?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-6762: ------------------------------------ Is your JGroups traffic configured to use a loopback interface? This is the default. Disabling the "network" on your host won't actually disable this interface, as you are likely only disabling a non-loopback interface. > Wildfly cluster failover test not working as expected on windows OS, when network is disabled on a VM(Node) or by shutting down the VM (Node). > ---------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6762 > URL: https://issues.jboss.org/browse/WFLY-6762 > Project: WildFly > Issue Type: Quality Risk > Components: Clustering > Affects Versions: 8.2.0.Final > Reporter: Preeta Kuruvilla > Assignee: Paul Ferraro > Priority: Blocker > > In your mail related to WFLY-6749 you has said the below :- > **The default stack contains the following failure detection protocols: > FD_SOCK > FD_ALL > These protocols are described here: > http://www.jgroups.org/manual/index.html#FailureDetection > I suspect that your method of simulating a failure - by disabling the network of the host machine is not being detected by FD_SOCK. It will however, be detected by FD_ALL, but only after 1 minute. The heartbeat timeout used by FD_ALL can be manipulated via the timeout property. > e.g. > <protocol type="FD_ALL" ><property name="timeout">60000</property></protocol> > ************************************************************************************************** > Thanks for the quick response on WFLY-6749. > Based on your suggestion, I had a taken a look at the testing scenarios mentioned in "Table 29. Failure detection behavior" in the link that you provided- http://www.jgroups.org/manual/index.html#FailureDetection. No where its mentioned that disabling a network on a node, is a valid testing scenario in Wildfly cluster. > The Failover is working properly when the network on a node is disabled on a weblogic cluster for our application. However it doesn't work and it hampers the application functionality on Wildfly cluster when we try to disable the network on a node in Wildfly cluster. > However as I said earlier, the failover on wildfly cluster works when we stop a node from admin console or give Ctrl + C to stop the services on a node. > Would like to get a confirmation from you that disabling the network on a node is not the valid failover testing scenario for wildfly cluster. > Also we tried to test the same failover scenario by Shutting down/power off a VM (node) in a wildfly cluster. It did not work for Windows Environment although it worked for linux environment. > Note: we are using Windows 2012 environment. Here is a link I found: http://stackoverflow.com/questions/31218710/unable-to-stop-wildfly-8-2-se... > https://developer.jboss.org/thread/238135?tstart=0 > Thanks, > Preeta -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2016