February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3565) RequestController ignores queued tasks if max requests is configured

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3565?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-3565: ---------------------------------------- Fix Version/s: 4.0.0.Beta1 Assignee: Christoph Böhme Resolution: Done Thanks! > RequestController ignores queued tasks if max requests is configured > -------------------------------------------------------------------- > > Key: WFCORE-3565 > URL: https://issues.jboss.org/browse/WFCORE-3565 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 3.0.8.Final, 4.0.0.Alpha7 > Reporter: Christoph Böhme > Assignee: Christoph Böhme > Fix For: 4.0.0.Beta1 > > > We encountered an issue with EJB timers stopping randomly if the container is under load. Sometimes the timers get stalled right after deployment without firing at all. Sometimes the timers work fine for a couple of days before they suddenly stop working. The timers are defined using the {{@Scheduled}} annotation. > We found out that the reason for the randomly stopping timers is a bug in the {{RequestController}} class which only appears if a maximum number of requests is configured in the request controller subsystem. If a timer is being triggered while the container has reached the request limit then the timer is put into a task queue to be processed later. However, the task queue is never checked for queued tasks if the request number goes down again. This leaves the timers stuck in the queue. Since every timer needs to reregister after it has been triggered, the timers appear to have stopped. > In old versions of the {{RequestController}} class from before release wildfly-core-1.0.0.Alpha14 it looks like the idea was to check for queued requests whenever a request finished (see [here|https://github.com/wildfly/wildfly-core/blob/a426a14db6466549159a552...]). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9780) Minimize module dependencies

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9780?page=com.atlassian.jira.plugin.... ] David Lloyd reassigned WFLY-9780: --------------------------------- Assignee: David Lloyd (was: Jason Greene) > Minimize module dependencies > ---------------------------- > > Key: WFLY-9780 > URL: https://issues.jboss.org/browse/WFLY-9780 > Project: WildFly > Issue Type: Task > Reporter: David Lloyd > Assignee: David Lloyd > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2234) Unlocked locks stay locked forever

by David White (JIRA)

[ https://issues.jboss.org/browse/JGRP-2234?page=com.atlassian.jira.plugin.... ] David White commented on JGRP-2234: ----------------------------------- Bela - please clarify. For the simple solution does the application that uses JGroups need to implement any part of that solution, or is the simple solution all handled within JGroups itself? (i.e. RELEASE_LOCK request, RELEASE_LOCK_OK acknowledgment from coordinator, releasing member adding the release request to a list and resend the requests on coordinator change). Thanks. > Unlocked locks stay locked forever > ---------------------------------- > > Key: JGRP-2234 > URL: https://issues.jboss.org/browse/JGRP-2234 > Project: JGroups > Issue Type: Bug > Reporter: Bram Klein Gunnewiek > Assignee: Bela Ban > Fix For: 4.0.11 > > Attachments: ClusterSplitLockTest.java, jg_clusterlock_output_testfail.txt > > > As discussed in the mailing list we have issues where locks from the central lock protocol stay locked forever when the coordinator of the cluster disconnects. We can reproduce this with the attached ClusterSplitLockTest.java. Its a race condition and we need to run the test a lot of times (sometimes > 20) before we encounter a failure. > What we think is happening: > In a three node cluster (node A, B and C where node A is the coordinator) unlock requests from B and/or C can be missed when node A leaves and B and/or C don't have the new view installed yet. When, for example, node B takes over coordination it creates the lock table based on the back-ups. Lets say node C has locked the lock with name 'lockX'. Node C performs an unlock of 'lockX' just after node A (gracefully) leaves and sends the unlock request to node A since node C doesn't have the correct view installed yet. Node B has recreated the lock table where 'lockX' is locked by Node C. Node C doesn't resend the unlock request so 'lockX' gets locked forever. > Attached is the testng test we wrote and the output of a test failure. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3588) Intermittent failures in LoggingSubsystemRollbackTestCase

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3588?page=com.atlassian.jira.plugi... ] Stuart Douglas updated WFCORE-3588: ----------------------------------- Component/s: Test Suite > Intermittent failures in LoggingSubsystemRollbackTestCase > --------------------------------------------------------- > > Key: WFCORE-3588 > URL: https://issues.jboss.org/browse/WFCORE-3588 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > Seems to happen on windows due to byteman's inability to bind a ServerSocket. Changing all the byteman tests to use different ports should fix this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9782) Intermittent failures in LoggingSubsystemRollbackTestCase

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-9782: ------------------------------------ Summary: Intermittent failures in LoggingSubsystemRollbackTestCase Key: WFLY-9782 URL: https://issues.jboss.org/browse/WFLY-9782 Project: WildFly Issue Type: Bug Reporter: Stuart Douglas Assignee: Jason Greene Seems to happen on windows due to byteman's inability to bind a ServerSocket. Changing all the byteman tests to use different ports should fix this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9782) Intermittent failures in LoggingSubsystemRollbackTestCase

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-9782?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-9782: ------------------------------------ Assignee: Stuart Douglas (was: Jason Greene) > Intermittent failures in LoggingSubsystemRollbackTestCase > --------------------------------------------------------- > > Key: WFLY-9782 > URL: https://issues.jboss.org/browse/WFLY-9782 > Project: WildFly > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > Seems to happen on windows due to byteman's inability to bind a ServerSocket. Changing all the byteman tests to use different ports should fix this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3588) Intermittent failures in LoggingSubsystemRollbackTestCase

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3588?page=com.atlassian.jira.plugi... ] Stuart Douglas moved WFLY-9782 to WFCORE-3588: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-3588 (was: WFLY-9782) > Intermittent failures in LoggingSubsystemRollbackTestCase > --------------------------------------------------------- > > Key: WFCORE-3588 > URL: https://issues.jboss.org/browse/WFCORE-3588 > Project: WildFly Core > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > Seems to happen on windows due to byteman's inability to bind a ServerSocket. Changing all the byteman tests to use different ports should fix this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9781) Support Forwarded HTTP Extension - RFC 7239

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-9781?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved EAP7-906 to WFLY-9781: ------------------------------------------- Project: WildFly (was: EAP 7 Planning Pilot) Key: WFLY-9781 (was: EAP7-906) Issue Type: Feature Request (was: Requirement) Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 1.2) Component/s: Web (Undertow) (was: Undertow) Polarion Test Plan: (was: https://polarion.engineering.redhat.com/polarion/#/project/EAP7/wiki/RFEs...) Analysis Document: (was: https://github.com/wildfly/wildfly-proposals/pull/5) > Support Forwarded HTTP Extension - RFC 7239 > ------------------------------------------- > > Key: WFLY-9781 > URL: https://issues.jboss.org/browse/WFLY-9781 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Labels: tp_candidate > > "X-Forwarded-For, X-Forwarded-By, and X-Forwarded-Proto" headers are non-standards headers and implementations might vary in different environments. > RFC-7239 standardizes a header field called "Forwarded" and provides the syntax and semantics for disclosing such information. I see that now a days most of the vendors supporting this including routes in "Openshift container platform" but due to lack of support in Undertow limiting us to relay on X-Forwarded-For* headers. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9780) Minimize module dependencies

by David Lloyd (JIRA)

David Lloyd created WFLY-9780: --------------------------------- Summary: Minimize module dependencies Key: WFLY-9780 URL: https://issues.jboss.org/browse/WFLY-9780 Project: WildFly Issue Type: Task Reporter: David Lloyd Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3587) Minimize module dependencies

by David Lloyd (JIRA)

David Lloyd created WFCORE-3587: ----------------------------------- Summary: Minimize module dependencies Key: WFCORE-3587 URL: https://issues.jboss.org/browse/WFCORE-3587 Project: WildFly Core Issue Type: Task Reporter: David Lloyd Assignee: David Lloyd -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 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 February 2018