October 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it

by Dennis Reed (Jira)

[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ] Dennis Reed updated JGRP-2387: ------------------------------ Description: If a FD_SOCK control message from a non-member is seen by FD_SOCK, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change. This does not cause any functional issues in the cluster, but can cause repeated WARN logs in some cases. was:If a FD_SOCK control message from a non-member is seen by FD_SOCK, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change. > Message from a non-member causes FD_ALL to continually suspect it > ----------------------------------------------------------------- > > Key: JGRP-2387 > URL: https://issues.jboss.org/browse/JGRP-2387 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Major > > If a FD_SOCK control message from a non-member is seen by FD_SOCK, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change. > This does not cause any functional issues in the cluster, but can cause repeated WARN logs in some cases. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it

by Dennis Reed (Jira)

[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ] Dennis Reed commented on JGRP-2387: ----------------------------------- Two potential solutions: - verify the node is a cluster member before adding an entry to timestamps. - add to timestamps, but then when sending a suspect event verify it's a member of the cluster. If not, remove from timestamps and ignore. (this one may be lower impact than checking on every message) > Message from a non-member causes FD_ALL to continually suspect it > ----------------------------------------------------------------- > > Key: JGRP-2387 > URL: https://issues.jboss.org/browse/JGRP-2387 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Major > > If a FD_SOCK control message from a non-member is seen by FD_SOCK, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it

by Dennis Reed (Jira)

[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ] Dennis Reed commented on JGRP-2387: ----------------------------------- This was first observed when a node leaving the cluster triggered it. It caused continuous WARN logs from FD_ALL suspecting the node (DEBUG in most other versions of JGroups), and WARN "no physical address" logs because the member had been removed from the address cache. > Message from a non-member causes FD_ALL to continually suspect it > ----------------------------------------------------------------- > > Key: JGRP-2387 > URL: https://issues.jboss.org/browse/JGRP-2387 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Major > > If a FD_SOCK control message from a non-member is seen by FD_SOCK, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it

by Dennis Reed (Jira)

[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ] Dennis Reed commented on JGRP-2387: ----------------------------------- The technical detail: FD_SOCK keeps track of the time the last message from each member was seen in the "timestamps" map. It periodically suspects any entries in this map whose timestamps are too old. When a new view is installed, any members that left are removed from the map, and an entry is added for each member if it doesn't already exist. When any FD_SOCK message is received from a member its entry in "timestamps" is updated. If msg_counts_as_heartbeat is on then the same is done for every message from that member. (this is off by default) The problem: When it updates the timestamp, no membership check is done first. So a message from a non-member triggers an entry added to the table, which is never removed until the next view is processed, and will continually send suspect events up the stack. This triggers VERIFY_SUSPECT to try to ping it, which it can't because it doesn't have the address (but can cause a "no physical address" log in some cases). VERIFY_SUSPECT will eventually send SUSPECT events up the stack, which are ignored by GMS because the node isn't part of the cluster. > Message from a non-member causes FD_ALL to continually suspect it > ----------------------------------------------------------------- > > Key: JGRP-2387 > URL: https://issues.jboss.org/browse/JGRP-2387 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Major > > If a FD_SOCK control message from a non-member is seen by FD_SOCK, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4599) [DMN Designer] Decision Tables: Hit Policy select drop-down remains visible if popover closed

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-4599?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-4599: ----------------------------------- Attachment: DROOLS-4599-1.png > [DMN Designer] Decision Tables: Hit Policy select drop-down remains visible if popover closed > --------------------------------------------------------------------------------------------- > > Key: DROOLS-4599 > URL: https://issues.jboss.org/browse/DROOLS-4599 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.28.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: DROOLS-4599-1.png, DROOLS-4599-2.png > > > The _drop down_ component of the Hit Policy _select_ component remains visible if the popover is dismissed by clicking elsewhere (outside the popover). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4599) [DMN Designer] Decision Tables: Hit Policy select drop-down remains visible if popover closed

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-4599?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-4599: ----------------------------------- Attachment: DROOLS-4599-2.png > [DMN Designer] Decision Tables: Hit Policy select drop-down remains visible if popover closed > --------------------------------------------------------------------------------------------- > > Key: DROOLS-4599 > URL: https://issues.jboss.org/browse/DROOLS-4599 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.28.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: DROOLS-4599-1.png, DROOLS-4599-2.png > > > The _drop down_ component of the Hit Policy _select_ component remains visible if the popover is dismissed by clicking elsewhere (outside the popover). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4599) [DMN Designer] Decision Tables: Hit Policy select drop-down remains visible if popover closed

by Michael Anstis (Jira)

Michael Anstis created DROOLS-4599: -------------------------------------- Summary: [DMN Designer] Decision Tables: Hit Policy select drop-down remains visible if popover closed Key: DROOLS-4599 URL: https://issues.jboss.org/browse/DROOLS-4599 Project: Drools Issue Type: Bug Components: DMN Editor Affects Versions: 7.28.0.Final Reporter: Michael Anstis Assignee: Michael Anstis The _drop down_ component of the Hit Policy _select_ component remains visible if the popover is dismissed by clicking elsewhere (outside the popover). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it

by Dennis Reed (Jira)

Dennis Reed created JGRP-2387: --------------------------------- Summary: Message from a non-member causes FD_ALL to continually suspect it Key: JGRP-2387 URL: https://issues.jboss.org/browse/JGRP-2387 Project: JGroups Issue Type: Bug Affects Versions: 4.0.1 Reporter: Dennis Reed Assignee: Bela Ban If a FD_SOCK control message from a non-member is seen by FD_SOCK, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-11978) EAR with 2+ JPA does not shutdown cleanly

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFLY-11978?page=com.atlassian.jira.plugin... ] Scott Marlow commented on WFLY-11978: ------------------------------------- [~dlmiles] Could you please try to recreate with WildFly 18.0.0.Final, which should be released soon. Thanks, Scott > EAR with 2+ JPA does not shutdown cleanly > ----------------------------------------- > > Key: WFLY-11978 > URL: https://issues.jboss.org/browse/WFLY-11978 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 16.0.0.Final > Environment: Windows JDK8 WF16 > Reporter: Darryl Miles > Assignee: Scott Marlow > Priority: Major > Attachments: td8948.txt > > > EAR with 2+ JPA does not shutdown cleanly. > I see in the logs each JPA project have an entry: > WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'blah....jpa.project1' > WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'blah....jpa.project2' > then a few lines later: > WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service 'blah....jpa.project2' > I never see the "phase 1 of 2" entry for "jpa.project1" in the log. > The container will wait 300 seconds and timeout. > The management console during the time shows > Operation: undeploy > Execution Status: awaiting-stablility. > The container is killed and the configuration.xml still contains the EAR deployment info, as undeploy did not complete. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-11887) [CVE-2016-3720]: Usage of vulnarable Jackson 1.9.13 libraries

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11887?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11887: ------------------------------------ Attachment: redhat-0006.txt > [CVE-2016-3720]: Usage of vulnarable Jackson 1.9.13 libraries > ------------------------------------------------------------- > > Key: WFLY-11887 > URL: https://issues.jboss.org/browse/WFLY-11887 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 14.0.0.Final > Reporter: Radoslav Ivanov > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 18.0.0.Final > > Attachments: redhat-0006.txt > > > We have a couple of high prio vulnerabilities reported around usage of Jackson libraries on WildFly with regards to CVE-2016-3720: > {code:java} > jackson-core-asl-1.9.13.jar > jackson-jaxrs-1.9.13.jar > jackson-mapper-asl-1.9.13.jar > jackson-xc-1.9.13.jar > {code} > Could you please review and remove/update them? -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

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 October 2019