December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1188) Exiting CLI requires stty sane command to be issued on Linux

by Ståle Pedersen (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1188?page=com.atlassian.jira.plugi... ] Ståle Pedersen commented on WFCORE-1188: ---------------------------------------- Hi, i've debugged a bit and it seems that jboss-cli call Console.stop() in æsh correctly, but it calls System.exit(..) before all of the threads in æsh have finished with the cleanup which is why the terminal is not reset correctly. > Exiting CLI requires stty sane command to be issued on Linux > ------------------------------------------------------------ > > Key: WFCORE-1188 > URL: https://issues.jboss.org/browse/WFCORE-1188 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.4.Final > Environment: Fedora 23 > Linux 4.2.6-301.fc23.x86_64 #1 SMP Fri Nov 20 22:22:41 UTC 2015 GNU/Linux > openjdk version "1.8.0_65" > OpenJDK Runtime Environment (build 1.8.0_65-b17) > OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode) > Reporter: James Perkins > Assignee: Alexey Loubyansky > > The PR https://github.com/wildfly/wildfly-core/pull/1268/ seemed to have introduced a regression where some times (seems to be most in my case) {{stty sane}} is required to get a shell back to normal. My guess is it's the aesh upgrade, but I'm not certain on that so I'll start the JIRA here and it can be moved to AESH if necessary. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5818) Quick redeploy vulnerable to CacheRegistry entry loss

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5818?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-5818. ------------------------------ Resolution: Rejected > Quick redeploy vulnerable to CacheRegistry entry loss > ----------------------------------------------------- > > Key: WFLY-5818 > URL: https://issues.jboss.org/browse/WFLY-5818 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > On deploy, CacheRegistry adds its local entry to the cache, and on undeploy removes it entry. However, we use a topology change listener to remove entries for crashed members (since these nodes will not have removed their local entry). However, since the listener is triggered asynchronously, it is possible that the topology change fired in response to an undeploy execute *after* the redeployed CacheRegistry starts - which would cause erroneous removal of the local entry that was added. > This manifests itself as an intermittent failure of the RegistryTestCase as seen in this PR: > https://github.com/wildfly/wildfly/pull/8465 > Not surprisingly, this issue only surfaces in the windoze runs, which, according to [~ctomc], execute faster than the linux runs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5819) EJB clustering 1.1 schema propagates unused clustered attribute

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5819?page=com.atlassian.jira.plugin.... ] Paul Ferraro moved JBEAP-2299 to WFLY-5819: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-5819 (was: JBEAP-2299) Workflow: GIT Pull Request workflow (was: CDW v1) Component/s: Clustering EJB (was: Clustering) (was: EJB) Target Release: (was: 7.0.0.GA) Affects Version/s: 10.0.0.CR4 (was: 7.0.0.ER2 (Beta)) > EJB clustering 1.1 schema propagates unused clustered attribute > --------------------------------------------------------------- > > Key: WFLY-5819 > URL: https://issues.jboss.org/browse/WFLY-5819 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 10.0.0.CR4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Version 1.1 of the ejb clustering schema includes an obsolete "clustered" attribute which should have been removed entirely. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5818) Quick redeploy vulnerable to CacheRegistry entry loss

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-5818: ---------------------------------- Summary: Quick redeploy vulnerable to CacheRegistry entry loss Key: WFLY-5818 URL: https://issues.jboss.org/browse/WFLY-5818 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.CR4 Reporter: Paul Ferraro Assignee: Paul Ferraro On deploy, CacheRegistry adds its local entry to the cache, and on undeploy removes it entry. However, we use a topology change listener to remove entries for crashed members (since these nodes will not have removed their local entry). However, since the listener is triggered asynchronously, it is possible that the topology change fired in response to an undeploy execute *after* the redeployed CacheRegistry starts - which would cause erroneous removal of the local entry that was added. This manifests itself as an intermittent failure of the RegistryTestCase as seen in this PR: https://github.com/wildfly/wildfly/pull/8465 Not surprisingly, this issue only surfaces in the windoze runs, which, according to [~ctomc], execute faster than the linux runs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5818) Quick redeploy vulnerable to CacheRegistry entry loss

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5818?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-5818. ------------------------------ Resolution: Done opened by mistake. Stupid jira interface... > Quick redeploy vulnerable to CacheRegistry entry loss > ----------------------------------------------------- > > Key: WFLY-5818 > URL: https://issues.jboss.org/browse/WFLY-5818 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > On deploy, CacheRegistry adds its local entry to the cache, and on undeploy removes it entry. However, we use a topology change listener to remove entries for crashed members (since these nodes will not have removed their local entry). However, since the listener is triggered asynchronously, it is possible that the topology change fired in response to an undeploy execute *after* the redeployed CacheRegistry starts - which would cause erroneous removal of the local entry that was added. > This manifests itself as an intermittent failure of the RegistryTestCase as seen in this PR: > https://github.com/wildfly/wildfly/pull/8465 > Not surprisingly, this issue only surfaces in the windoze runs, which, according to [~ctomc], execute faster than the linux runs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5818) Quick redeploy vulnerable to CacheRegistry entry loss

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5818?page=com.atlassian.jira.plugin.... ] Paul Ferraro reopened WFLY-5818: -------------------------------- > Quick redeploy vulnerable to CacheRegistry entry loss > ----------------------------------------------------- > > Key: WFLY-5818 > URL: https://issues.jboss.org/browse/WFLY-5818 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > On deploy, CacheRegistry adds its local entry to the cache, and on undeploy removes it entry. However, we use a topology change listener to remove entries for crashed members (since these nodes will not have removed their local entry). However, since the listener is triggered asynchronously, it is possible that the topology change fired in response to an undeploy execute *after* the redeployed CacheRegistry starts - which would cause erroneous removal of the local entry that was added. > This manifests itself as an intermittent failure of the RegistryTestCase as seen in this PR: > https://github.com/wildfly/wildfly/pull/8465 > Not surprisingly, this issue only surfaces in the windoze runs, which, according to [~ctomc], execute faster than the linux runs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5817) Read resource of deployment with faulty datasource fails

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-5817: --------------------------------- Summary: Read resource of deployment with faulty datasource fails Key: WFLY-5817 URL: https://issues.jboss.org/browse/WFLY-5817 Project: WildFly Issue Type: Bug Components: Domain Management Reporter: Tomaz Cerar Assignee: Tomaz Cerar For the setup see HAL-1006. Reading the deployments of a server which contains a deployment with a faulty datasource, yields an undefined result: {code} /host=master/server=server-one:read-children-resources(child-type=deployment,recursive=true,include-runtime=true) { "outcome" => "success", "result" => undefined, "failure-description" => undefined } {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5816) Quick redeploy vulnerable to CacheRegistry entry loss

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-5816: ---------------------------------- Summary: Quick redeploy vulnerable to CacheRegistry entry loss Key: WFLY-5816 URL: https://issues.jboss.org/browse/WFLY-5816 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.CR4 Reporter: Paul Ferraro Assignee: Paul Ferraro On deploy, CacheRegistry adds its local entry to the cache, and on undeploy removes it entry. However, we use a topology change listener to remove entries for crashed members (since these nodes will not have removed their local entry). However, since the listener is triggered asynchronously, it is possible that the topology change fired in response to an undeploy execute *after* the redeployed CacheRegistry starts - which would cause erroneous removal of the local entry that was added. This manifests itself as an intermittent failure of the RegistryTestCase as seen in this PR: https://github.com/wildfly/wildfly/pull/8465 Not surprisingly, this issue only surfaces in the windoze runs, which, according to [~ctomc], execute faster than the linux runs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1305) Performance degradation using fair semaphores in heavily contended workloads

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1305?page=com.atlassian.jira.plugin... ] Tom Jenkinson updated JBJCA-1305: --------------------------------- Forum Reference: https://groups.google.com/forum/#!topic/ironjacamar-developers/2AsxToycwcQ > Performance degradation using fair semaphores in heavily contended workloads > ---------------------------------------------------------------------------- > > Key: JBJCA-1305 > URL: https://issues.jboss.org/browse/JBJCA-1305 > Project: IronJacamar > Issue Type: Enhancement > Components: Core > Affects Versions: WildFly/IronJacamar 1.3.1.Final > Reporter: John O'Hara > Assignee: Jesper Pedersen > > Under heavy contention, a fair semaphore causes performance degradation for threads trying to acquire a permit from the semaphore. Changing the semaphore to not fair alleviates the performance degradation under heavy contention. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1197) Enhance missing capability logging during subsystem testing

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-1197: ---------------------------------------- Summary: Enhance missing capability logging during subsystem testing Key: WFCORE-1197 URL: https://issues.jboss.org/browse/WFCORE-1197 Project: WildFly Core Issue Type: Enhancement Components: Test Suite Affects Versions: 2.0.4.Final Reporter: Darran Lofthouse Assignee: Tomaz Cerar Fix For: 3.0.0.Alpha1 Making changes to the Undertow subsystem I was presented with the following failure: - {noformat} <testcase name="testRuntime" classname="org.wildfly.extension.undertow.UndertowSubsystemTestCase" time="1.611"> <error type="java.lang.NullPointerException:">java.lang.NullPointerException: null at org.wildfly.extension.undertow.UndertowSubsystemTestCase.testRuntime(UndertowSubsystemTestCase.java:118) {noformat} It was only after enabling other logging I found the real cause: - {noformat} ec 08, 2015 6:19:22 PM org.jboss.as.controller.OperationContextImpl validateCapabilities ERROR: WFLYCTL0362: Capabilities required by resource '/subsystem=undertow/application-security-domain=other' are not available: org.wildfly.security.http-server-mechanism-factory.elytron-factory; There are no known registration points which can provide this capability. {noformat} The NullPointerException above is because it is detected the booting failed but the error was never made available. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2015