July 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4850) ManagementClient.isServerInRunningState fails when server is stopped

by Ondřej Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-4850?page=com.atlassian.jira.plugin.... ] Ondřej Chaloupka commented on WFLY-4850: ---------------------------------------- I see. Then what to add to catch block the AssertionError (as ActiveOperationSupport behaves in such way) The place where I catch this is extended clustering test {{ClusterPassivationTestCase}}. Running like {code} ./integration-tests.sh clean install -Dts.noSmoke -Dts.clust -Dintegration.module -DextendedTests -Dtest=ClusterPassivationTestCase {code} Nevertheless in any test in testsuite where server is managed manually, where the check for {{isServerInRunningState}} is used and server is stopped at that time will occur that assertion exception instead of {{false}} is returned. > ManagementClient.isServerInRunningState fails when server is stopped > -------------------------------------------------------------------- > > Key: WFLY-4850 > URL: https://issues.jboss.org/browse/WFLY-4850 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Ondřej Chaloupka > Assignee: Tomaz Cerar > > Scenario: server is stopped (killed), working with arquillian to check if server is started or not > Current implementation of the {{ManagementClient.isServerInRunningState}} catches only {{IOException}} (see [1]) and in such case false is returned. Otherwise exception is propagated upwards. > That's a problem in case that assertions are enabled - which is true statement for wildfly testsuite (see pom.xml, surefire configuration and {{<enableAssertions>true</enableAssertions>}}). As state of the server is checked with assertions as well [2] then test fails on such assertion instead of getting false as server is stopped. > In comparision with arquillian client for jboss-eap there is caught {{Throwable}} and returned false [3] which seems to me more correct. > Could you, please, forwardport arquillian client behaviour from JBoss EAP to WildFly? > [1] https://github.com/wildfly/wildfly-arquillian/blob/master/common/src/main... > [2] https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/jav... > [3] https://github.com/jbossas/jboss-eap/blob/6.x/arquillian/common/src/main/... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4850) ManagementClient.isServerInRunningState fails when server is stopped

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4850?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-4850: ----------------------------------- Current change was done to fix WFLY-2140 What kind of exception is thrown in your scenario? What we could do is to catch runtime exception and propagate that, but for all other kind of exceptions we would return false. Just not sure if this would solve your problem. > ManagementClient.isServerInRunningState fails when server is stopped > -------------------------------------------------------------------- > > Key: WFLY-4850 > URL: https://issues.jboss.org/browse/WFLY-4850 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Ondřej Chaloupka > Assignee: Tomaz Cerar > > Scenario: server is stopped (killed), working with arquillian to check if server is started or not > Current implementation of the {{ManagementClient.isServerInRunningState}} catches only {{IOException}} (see [1]) and in such case false is returned. Otherwise exception is propagated upwards. > That's a problem in case that assertions are enabled - which is true statement for wildfly testsuite (see pom.xml, surefire configuration and {{<enableAssertions>true</enableAssertions>}}). As state of the server is checked with assertions as well [2] then test fails on such assertion instead of getting false as server is stopped. > In comparision with arquillian client for jboss-eap there is caught {{Throwable}} and returned false [3] which seems to me more correct. > Could you, please, forwardport arquillian client behaviour from JBoss EAP to WildFly? > [1] https://github.com/wildfly/wildfly-arquillian/blob/master/common/src/main... > [2] https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/jav... > [3] https://github.com/jbossas/jboss-eap/blob/6.x/arquillian/common/src/main/... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4850) ManagementClient.isServerInRunningState fails when server is stopped

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4850?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-4850: --------------------------------- Assignee: Tomaz Cerar (was: Jason Greene) > ManagementClient.isServerInRunningState fails when server is stopped > -------------------------------------------------------------------- > > Key: WFLY-4850 > URL: https://issues.jboss.org/browse/WFLY-4850 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Ondřej Chaloupka > Assignee: Tomaz Cerar > > Scenario: server is stopped (killed), working with arquillian to check if server is started or not > Current implementation of the {{ManagementClient.isServerInRunningState}} catches only {{IOException}} (see [1]) and in such case false is returned. Otherwise exception is propagated upwards. > That's a problem in case that assertions are enabled - which is true statement for wildfly testsuite (see pom.xml, surefire configuration and {{<enableAssertions>true</enableAssertions>}}). As state of the server is checked with assertions as well [2] then test fails on such assertion instead of getting false as server is stopped. > In comparision with arquillian client for jboss-eap there is caught {{Throwable}} and returned false [3] which seems to me more correct. > Could you, please, forwardport arquillian client behaviour from JBoss EAP to WildFly? > [1] https://github.com/wildfly/wildfly-arquillian/blob/master/common/src/main... > [2] https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/jav... > [3] https://github.com/jbossas/jboss-eap/blob/6.x/arquillian/common/src/main/... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4850) ManagementClient.isServerInRunningState fails when server is stopped

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4850?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-4850: ------------------------------ Component/s: Test Suite > ManagementClient.isServerInRunningState fails when server is stopped > -------------------------------------------------------------------- > > Key: WFLY-4850 > URL: https://issues.jboss.org/browse/WFLY-4850 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Ondřej Chaloupka > Assignee: Jason Greene > > Scenario: server is stopped (killed), working with arquillian to check if server is started or not > Current implementation of the {{ManagementClient.isServerInRunningState}} catches only {{IOException}} (see [1]) and in such case false is returned. Otherwise exception is propagated upwards. > That's a problem in case that assertions are enabled - which is true statement for wildfly testsuite (see pom.xml, surefire configuration and {{<enableAssertions>true</enableAssertions>}}). As state of the server is checked with assertions as well [2] then test fails on such assertion instead of getting false as server is stopped. > In comparision with arquillian client for jboss-eap there is caught {{Throwable}} and returned false [3] which seems to me more correct. > Could you, please, forwardport arquillian client behaviour from JBoss EAP to WildFly? > [1] https://github.com/wildfly/wildfly-arquillian/blob/master/common/src/main... > [2] https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/jav... > [3] https://github.com/jbossas/jboss-eap/blob/6.x/arquillian/common/src/main/... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-786) Remove temporary code to make compatible with WF core

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-786?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-786: ------------------------------ Fix Version/s: 2.0.0.Alpha6 (was: 2.0.0.Alpha4) > Remove temporary code to make compatible with WF core > ----------------------------------------------------- > > Key: WFCORE-786 > URL: https://issues.jboss.org/browse/WFCORE-786 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 2.0.0.Alpha6 > > > Some temporary code is needed in core to preserve compatibility with Wildfly following the work done on WFCORE-401. This should be removed and WildFly should be adjusted once this is all in a core release. > The changes are > * org.jboss.as.controller.resource.SocketBindingGroupResourceDefinition should be removed (This was meant to be done for WFCORE-726 but somehow missed) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-786) Remove temporary code to make compatible with WF core

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-786?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-786: ------------------------------ Description: Some temporary code is needed in core to preserve compatibility with Wildfly following the work done on WFCORE-401. This should be removed and WildFly should be adjusted once this is all in a core release. The changes are * org.jboss.as.controller.resource.SocketBindingGroupResourceDefinition should be removed (This was meant to be done for WFCORE-726 but somehow missed) was: Some temporary code is needed in core to preserve compatibility with Wildfly following the work done on WFCORE-401. This should be removed and WildFly should be adjusted once this is all in a core release. The changes are * Common.xml's default constructor should be removed * org.jboss.as.controller.resource.SocketBindingGroupResourceDefinition should be removed > Remove temporary code to make compatible with WF core > ----------------------------------------------------- > > Key: WFCORE-786 > URL: https://issues.jboss.org/browse/WFCORE-786 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 2.0.0.Alpha4 > > > Some temporary code is needed in core to preserve compatibility with Wildfly following the work done on WFCORE-401. This should be removed and WildFly should be adjusted once this is all in a core release. > The changes are > * org.jboss.as.controller.resource.SocketBindingGroupResourceDefinition should be removed (This was meant to be done for WFCORE-726 but somehow missed) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-786) Remove temporary code to make compatible with WF core

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-786: --------------------------------- Summary: Remove temporary code to make compatible with WF core Key: WFCORE-786 URL: https://issues.jboss.org/browse/WFCORE-786 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Kabir Khan Assignee: Kabir Khan Fix For: 2.0.0.Alpha4 Some temporary code is needed in core to preserve compatibility with Wildfly following the work done on WFCORE-401. This should be removed and WildFly should be adjusted once this is all in a core release. The changes are * Common.xml's default constructor should be removed * org.jboss.as.controller.resource.SocketBindingGroupResourceDefinition should be removed -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4827) Network Connection leak on client abort connection

by Andrea Bertolini (JIRA)

[ https://issues.jboss.org/browse/WFLY-4827?page=com.atlassian.jira.plugin.... ] Andrea Bertolini commented on WFLY-4827: ---------------------------------------- Skipping tests I succeed in building jars. Now I'm going to test this new version. > Network Connection leak on client abort connection > -------------------------------------------------- > > Key: WFLY-4827 > URL: https://issues.jboss.org/browse/WFLY-4827 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow), Web Sockets > Affects Versions: 8.2.0.Final > Environment: On Windows Server 2012, JDK 1.8.0_45, Wildfly 8.2.0.Final in standalone mode. > Reporter: Andrea Bertolini > Assignee: Stuart Douglas > > We have a classic client-server application, all written in Java. Each client is installed on a forklift which can move all around a large area. This area is under wi-fi coverage. > Sometimes the clients can have a bad connection quality and the client-server communication is interrupted; in such a case it takes too many seconds to be restored. > To fix this situation, we add a timeout client-side. After 5 seconds it aborts the call and tries again a second time. > To achieve this call we use apache httpcomponents library (version 4.4). We use the abort method of httppost to interrupt this call. > Server-side, we have a group of web-servlets which listen to the incoming calls, manage requests and send a response. > It appears that sometimes a communication remains stuck in reading or writing from/to the stream. When the client aborts the communication, an exception is thrown on the server caused by the channel being closed. > It happens that a large number of connections remains stuck in connection status 'established' (only server-side) even if the real connection is actually closed (client doesn't have that connection active anymore). > When the number of established connections grows up to 200, server stops responding on port 8080, so it cannot accept more connections and it seems to freeze. > We tried to add tcp-keep-alive=true and no-request-timeout=120000 on http-listener in undertow subsystem, but sometimes it removes idle connections after any incoming requests are received for 2 minutes, some other times it keep connections as established and doesn't close them. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4850) ManagementClient.isServerInRunningState fails when server is stopped

by Ondřej Chaloupka (JIRA)

Ondřej Chaloupka created WFLY-4850: -------------------------------------- Summary: ManagementClient.isServerInRunningState fails when server is stopped Key: WFLY-4850 URL: https://issues.jboss.org/browse/WFLY-4850 Project: WildFly Issue Type: Bug Reporter: Ondřej Chaloupka Assignee: Jason Greene Scenario: server is stopped (killed), working with arquillian to check if server is started or not Current implementation of the {{ManagementClient.isServerInRunningState}} catches only {{IOException}} (see [1]) and in such case false is returned. Otherwise exception is propagated upwards. That's a problem in case that assertions are enabled - which is true statement for wildfly testsuite (see pom.xml, surefire configuration and {{<enableAssertions>true</enableAssertions>}}). As state of the server is checked with assertions as well [2] then test fails on such assertion instead of getting false as server is stopped. In comparision with arquillian client for jboss-eap there is caught {{Throwable}} and returned false [3] which seems to me more correct. Could you, please, forwardport arquillian client behaviour from JBoss EAP to WildFly? [1] https://github.com/wildfly/wildfly-arquillian/blob/master/common/src/main... [2] https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/jav... [3] https://github.com/jbossas/jboss-eap/blob/6.x/arquillian/common/src/main/... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4748) Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1"

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-4748?page=com.atlassian.jira.plugin.... ] Tomas Hofman reopened WFLY-4748: -------------------------------- Hello Paul, this is still not quite working. The @ViewChanged annotated method you added is not receiving any merge events, it only gets triggered after split. I was poking around and found out that Infinispan have separate annotations @ViewChanged and @Merged and that only @Merged notifies about merge events. I tried to modify your fix and it works. I'm attaching new PR, close it if I'm wrong please :): https://github.com/wildfly/wildfly/pull/7685 > Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1" > -------------------------------------------------------------------------------------------------- > > Key: WFLY-4748 > URL: https://issues.jboss.org/browse/WFLY-4748 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2 > Reporter: Tomas Hofman > Assignee: Paul Ferraro > Fix For: 9.0.0.CR2, 10.0.0.Alpha3 > > > When cluster of two nodes with deployed singleton service (f.i. cluster-ha-singleton quickstart app) splits, merges, and splits again, one of the nodes fails to run the singleton service with error message "WFLYCLSV0006: Failed to reach *quorum of 1* for jboss.quickstart.ha.singleton.default2 service. No singleton master will be elected." - note the "quorum of 1". > This only happens after the second and other successive splits. After the first split both nodes execute the service correctly. > After analysis, it appears that nodes are never being added back to service providers cache upon cluster merge, because CacheServiceProviderRegistrationFactory#membershipChanged() is never called with 'merged' attribute set to 'true'. > I presume that call should come from ChannelCommandDispatcherFactory#viewAccepted(): > {code} > public void viewAccepted(View view) { > // ... > for (Listener listener: this.listeners) { > listener.membershipChanged(oldNodes, newNodes, view instanceof MergeView); > } > } > {code} > This method gets called, but the problem is that the 'listeners' list is empty, so no listener is actually notified. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

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 July 2015