October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-205) ManagedDMRContentTypeResource does not use a map with consistent ordering for storing content

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-205?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-205: ------------------------------------------------ Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1078062|https://bugzilla.redhat.com/show_bug.cgi?id=1078062] from NEW to ASSIGNED > ManagedDMRContentTypeResource does not use a map with consistent ordering for storing content > --------------------------------------------------------------------------------------------- > > Key: WFCORE-205 > URL: https://issues.jboss.org/browse/WFCORE-205 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha10 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > ManagedDMRContentTypeResource.content is used for generating an overall hash for the stored content, but it does not use consistent ordering (i.e. it needs to be a LinkedHashMap or perhaps a TreeMap.) The result is when another node in the domain receives an update it may calculate a different overall hash. > This is surfacing as failures in https://bugzilla.redhat.com/show_bug.cgi?id=1078062 when the master and slave are running on different JVM releases. Different VM releases often have different ordering behavior when iterating over the unordered collections. > I believe this is unlikely to result in real-world problems since any backup will persist its own version of the hash to its local copy of domain.xml, so there won't be any mismatch. The importance of the overall hash is that it allows the process to find the content in the repo when it is added. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-205) ManagedDMRContentTypeResource does not use a map with consistent ordering for storing content

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-205?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-205: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1078062 > ManagedDMRContentTypeResource does not use a map with consistent ordering for storing content > --------------------------------------------------------------------------------------------- > > Key: WFCORE-205 > URL: https://issues.jboss.org/browse/WFCORE-205 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha10 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > ManagedDMRContentTypeResource.content is used for generating an overall hash for the stored content, but it does not use consistent ordering (i.e. it needs to be a LinkedHashMap or perhaps a TreeMap.) The result is when another node in the domain receives an update it may calculate a different overall hash. > This is surfacing as failures in https://bugzilla.redhat.com/show_bug.cgi?id=1078062 when the master and slave are running on different JVM releases. Different VM releases often have different ordering behavior when iterating over the unordered collections. > I believe this is unlikely to result in real-world problems since any backup will persist its own version of the hash to its local copy of domain.xml, so there won't be any mismatch. The importance of the overall hash is that it allows the process to find the content in the repo when it is added. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-205) ManagedDMRContentTypeResource does not use a map with consistent ordering for storing content

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-205: --------------------------------------- Summary: ManagedDMRContentTypeResource does not use a map with consistent ordering for storing content Key: WFCORE-205 URL: https://issues.jboss.org/browse/WFCORE-205 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha10 Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 1.0.0.Beta1 ManagedDMRContentTypeResource.content is used for generating an overall hash for the stored content, but it does not use consistent ordering (i.e. it needs to be a LinkedHashMap or perhaps a TreeMap.) The result is when another node in the domain receives an update it may calculate a different overall hash. This is surfacing as failures in https://bugzilla.redhat.com/show_bug.cgi?id=1078062 when the master and slave are running on different JVM releases. Different VM releases often have different ordering behavior when iterating over the unordered collections. I believe this is unlikely to result in real-world problems since any backup will persist its own version of the hash to its local copy of domain.xml, so there won't be any mismatch. The importance of the overall hash is that it allows the process to find the content in the repo when it is added. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1895) FLUSH_NOT_COMPLETED race condition

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/JGRP-1895?page=com.atlassian.jira.plugin.... ] Dennis Reed commented on JGRP-1895: ----------------------------------- Possible fix for the specific issue in my previous comment: When handling FLUSH_NOT_COMPLETED, if flushCompleted is true (which will never be the case if the FLUSH_NOT_COMPLETED is for the current flush), then just ignore it. > FLUSH_NOT_COMPLETED race condition > ---------------------------------- > > Key: JGRP-1895 > URL: https://issues.jboss.org/browse/JGRP-1895 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.6.16 > Reporter: Dennis Reed > Assignee: Dennis Reed > > FLUSH_NOT_COMPLETED does not keep track of which FLUSH it was related to. FLUSH_COMPLETED only keeps track of whether the FLUSH was for the current view. > If these responses are delayed (which can be caused by a long GC pause on the node sending it) where a new FLUSH has been started, these can be interpreted as responses for the wrong FLUSH. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1895) FLUSH_NOT_COMPLETED race condition

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/JGRP-1895?page=com.atlassian.jira.plugin.... ] Dennis Reed updated JGRP-1895: ------------------------------ Description: FLUSH_NOT_COMPLETED does not keep track of which FLUSH it was related to. FLUSH_COMPLETED only keeps track of whether the FLUSH was for the current view. If these responses are delayed (which can be caused by a long GC pause on the node sending it) where a new FLUSH has been started, these can be interpreted as responses for the wrong FLUSH. was: FLUSH_NOT_COMPLETED does not keep track of which FLUSH it was related to. FLUSH_COMPLETED only keeps track of whether the FLUSH was for the current view. If these responses are delayed (which can be G/caused by a long GC pause on the node sending it) where a new FLUSH has been started, these can be interpreted as responses for the wrong FLUSH. > FLUSH_NOT_COMPLETED race condition > ---------------------------------- > > Key: JGRP-1895 > URL: https://issues.jboss.org/browse/JGRP-1895 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.6.16 > Reporter: Dennis Reed > Assignee: Dennis Reed > > FLUSH_NOT_COMPLETED does not keep track of which FLUSH it was related to. FLUSH_COMPLETED only keeps track of whether the FLUSH was for the current view. > If these responses are delayed (which can be caused by > a long GC pause on the node sending it) where a new FLUSH has been started, these can be interpreted as responses for the wrong FLUSH. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1895) FLUSH_NOT_COMPLETED race condition

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/JGRP-1895?page=com.atlassian.jira.plugin.... ] Dennis Reed updated JGRP-1895: ------------------------------ Description: FLUSH_NOT_COMPLETED does not keep track of which FLUSH it was related to. FLUSH_COMPLETED only keeps track of whether the FLUSH was for the current view. If these responses are delayed (which can be caused by a long GC pause on the node sending it) where a new FLUSH has been started, these can be interpreted as responses for the wrong FLUSH. was: FLUSH_NOT_COMPLETED does not keep track of which FLUSH it was related to. FLUSH_COMPLETED only keeps track of whether the FLUSH was for the current view. If these responses are delayed (which can be caused by a long GC pause on the node sending it) where a new FLUSH has been started, these can be interpreted as responses for the wrong FLUSH. > FLUSH_NOT_COMPLETED race condition > ---------------------------------- > > Key: JGRP-1895 > URL: https://issues.jboss.org/browse/JGRP-1895 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.6.16 > Reporter: Dennis Reed > Assignee: Dennis Reed > > FLUSH_NOT_COMPLETED does not keep track of which FLUSH it was related to. FLUSH_COMPLETED only keeps track of whether the FLUSH was for the current view. > If these responses are delayed (which can be caused by a long GC pause on the node sending it) where a new FLUSH has been started, these can be interpreted as responses for the wrong FLUSH. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1895) FLUSH_NOT_COMPLETED race condition

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/JGRP-1895?page=com.atlassian.jira.plugin.... ] Dennis Reed commented on JGRP-1895: ----------------------------------- Specific case where this caused a major outage: A new node was joining the cluster (JOIN_REQ_WITH_STATE_TRANSFER). Cooordinator started flush. nodeB was in GC and didn't respond, so the flush timed out. Coordinator started another flush. nodeB responded to the original flush with FLUSH_COMPLETED, and the coordinator thought it was a response for the current flush when it was not. FLUSH completed (when it shouldn't have), and coordinator started a reconcile. nodeB then responded to the current FLUSH with FLUSH_NOT_COMPLETED, which set flush_promise to false to indicate a failure. Since the FLUSH actually succeeded, the coordinator did not abort it. But since it was reported as failing, the new node did not join the cluster, and so never stopped the FLUSH. FLUSH was then stuck in an incomplete state until the channel was restarted. > FLUSH_NOT_COMPLETED race condition > ---------------------------------- > > Key: JGRP-1895 > URL: https://issues.jboss.org/browse/JGRP-1895 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.6.16 > Reporter: Dennis Reed > Assignee: Dennis Reed > > FLUSH_NOT_COMPLETED does not keep track of which FLUSH it was related to. FLUSH_COMPLETED only keeps track of whether the FLUSH was for the current view. > If these responses are delayed (which can be G/caused by > a long GC pause on the node sending it) where a new FLUSH has been started, these can be interpreted as responses for the wrong FLUSH. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1895) FLUSH_NOT_COMPLETED race condition

by Dennis Reed (JIRA)

Dennis Reed created JGRP-1895: --------------------------------- Summary: FLUSH_NOT_COMPLETED race condition Key: JGRP-1895 URL: https://issues.jboss.org/browse/JGRP-1895 Project: JGroups Issue Type: Bug Affects Versions: 2.6.16 Reporter: Dennis Reed Assignee: Dennis Reed FLUSH_NOT_COMPLETED does not keep track of which FLUSH it was related to. FLUSH_COMPLETED only keeps track of whether the FLUSH was for the current view. If these responses are delayed (which can be G/caused by a long GC pause on the node sending it) where a new FLUSH has been started, these can be interpreted as responses for the wrong FLUSH. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3972) Missing security domain dependency

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3972?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3972: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1152105|https://bugzilla.redhat.com/show_bug.cgi?id=1152105] from MODIFIED to ON_QA > Missing security domain dependency > ---------------------------------- > > Key: WFLY-3972 > URL: https://issues.jboss.org/browse/WFLY-3972 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.1.0.Final > Reporter: Jesper Pedersen > Assignee: Stefano Maestri > Priority: Critical > Fix For: 8.2.0.CR1, 9.0.0.CR1 > > > Only DataSourceEnable appears to have a dependency defined against the security domain used (SecurityDomainService). > Also any security domain used in recovery needs a dependency. > Likewise for resource adapter deployments. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3939) jndiView operation from JConsole returns void

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3939?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3939: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1149987|https://bugzilla.redhat.com/show_bug.cgi?id=1149987] from MODIFIED to ON_QA > jndiView operation from JConsole returns void > --------------------------------------------- > > Key: WFLY-3939 > URL: https://issues.jboss.org/browse/WFLY-3939 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 8.1.0.Final > Reporter: Osamu Nagano > Assignee: Eduardo Martins > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > > When I press "jndiView" operation button (navigate jboss.as / naming / Operations in MBeans tab of JConsole), an info dialog box returns with message "Method successfully invoked". The contents of JNDI view is not printed anywhere. It should return that as String or dump the contents into stdout. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 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 October 2014