October 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2388) DNS_PING#destroy could yield NPE hiding the root cause

by Radoslav Husar (Jira)

Radoslav Husar created JGRP-2388: ------------------------------------ Summary: DNS_PING#destroy could yield NPE hiding the root cause Key: JGRP-2388 URL: https://issues.jboss.org/browse/JGRP-2388 Project: JGroups Issue Type: Bug Reporter: Radoslav Husar Assignee: Bela Ban Caused by: java.lang.NullPointerException at org.jgroups.protocols.dns.DNS_PING.destroy(DNS_PING.java:70) at java.util.ArrayList.forEach(ArrayList.java:1257) at org.jgroups.stack.ProtocolStack.destroy(ProtocolStack.java:876) at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:867) at org.jgroups.stack.ProtocolStack.init(ProtocolStack.java:849) at org.jgroups.JChannel.<init>(JChannel.java:155) at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:116) at org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.get(ChannelServiceConfigurator.java:96) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2388) DNS_PING#destroy could yield NPE hiding the root cause

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/JGRP-2388?page=com.atlassian.jira.plugin.... ] Radoslav Husar reassigned JGRP-2388: ------------------------------------ Assignee: Radoslav Husar (was: Bela Ban) > DNS_PING#destroy could yield NPE hiding the root cause > ------------------------------------------------------ > > Key: JGRP-2388 > URL: https://issues.jboss.org/browse/JGRP-2388 > Project: JGroups > Issue Type: Bug > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > Caused by: java.lang.NullPointerException > at org.jgroups.protocols.dns.DNS_PING.destroy(DNS_PING.java:70) > at java.util.ArrayList.forEach(ArrayList.java:1257) > at org.jgroups.stack.ProtocolStack.destroy(ProtocolStack.java:876) > at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:867) > at org.jgroups.stack.ProtocolStack.init(ProtocolStack.java:849) > at org.jgroups.JChannel.<init>(JChannel.java:155) > at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:116) > at org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.get(ChannelServiceConfigurator.java:96) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4563) Upgrade javax.validation from 1.0.0.GA to 2.0.1.Final

by Marek Novotny (Jira)

[ https://issues.jboss.org/browse/DROOLS-4563?page=com.atlassian.jira.plugi... ] Marek Novotny reassigned DROOLS-4563: ------------------------------------- Assignee: Marek Novotny (was: Michael Biarnes Kiefer) > Upgrade javax.validation from 1.0.0.GA to 2.0.1.Final > ------------------------------------------------------ > > Key: DROOLS-4563 > URL: https://issues.jboss.org/browse/DROOLS-4563 > Project: Drools > Issue Type: Feature Request > Reporter: Michael Biarnes Kiefer > Assignee: Marek Novotny > Priority: Optional > > To do the upgrade of javax.validation [(PR)|https://github.com/kiegroup/droolsjbpm-build-bootstrap/pull/1055] it is needed to check all GWT reps (uberfire, errai,wb etc) because the javax.validation version is not supported in these reps. > The version upgrade is needed for spring-boot and quarkus - so it should be upgraded in kie-parent but overwritten in all poms of GWT reps that doesn't support this new version by the old version. It is thought to add a dependency overwite in the root pom in those repo's to overwrite it to use the original older version > On the other hand existing overrides like [this|https://github.com/kiegroup/droolsjbpm-integration/blob/81415ae5cdc4...] should be removed then. > All reps should be examined if they have an override or if the need the old version. -- 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 Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2387: -------------------------------- Note: need to look at FD_ALL2, too. The second solution suggested by [~dereed] LGTM. > 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 > Fix For: 4.1.6 > > Attachments: Test.java > > > 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 Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2387 at 10/3/19 8:11 AM: --------------------------------------------------------- FD_ALL or FD_SOCK? I guess FD_ALL... Looking into this now... was (Author: belaban): FD_ALL or FD_SOCK? Looking into this now... > 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 > Fix For: 4.1.6 > > Attachments: Test.java > > > 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 Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2387: -------------------------------- FD_ALL or FD_SOCK? Looking into this now... > 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 > Fix For: 4.1.6 > > Attachments: Test.java > > > 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] (WFLY-12631) Server doesn't start when DNS_PING is configured

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-12631?page=com.atlassian.jira.plugin... ] Radoslav Husar reassigned WFLY-12631: ------------------------------------- Assignee: Radoslav Husar (was: Paul Ferraro) > Server doesn't start when DNS_PING is configured > ------------------------------------------------ > > Key: WFLY-12631 > URL: https://issues.jboss.org/browse/WFLY-12631 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Jean Francois Denise > Assignee: Radoslav Husar > Priority: Blocker > > NPE at start. > The root cause is that <module name="sun.jdk"/> is missing from org.wildfly.clustering.service module. > Exception: > Caused by: java.lang.NullPointerException > at org.jgroups.protocols.dns.DNS_PING.destroy(DNS_PING.java:70) > at java.util.ArrayList.forEach(ArrayList.java:1257) > at org.jgroups.stack.ProtocolStack.destroy(ProtocolStack.java:876) > at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:867) > at org.jgroups.stack.ProtocolStack.init(ProtocolStack.java:849) > at org.jgroups.JChannel.<init>(JChannel.java:155) > at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:116) > at org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.get(ChannelServiceConfigurator.java:96) > Hidden exception: > Failed instantiate InitialContextFactory com.sun.jndi.dns.DnsContextFactory from classloader ModuleClassLoader for Module "org.wildfly.clustering.service" version 18.0.0.Final-SNAPSHOT from local module loader @2d3fcdbd (finder: local module finder @617c74e5 (roots: /home/jdenise/workspaces/wildfly-jfdenise/build/target/wildfly-18.0.0.Final-SNAPSHOT/modules,/home/jdenise/workspaces/wildfly-jfdenise/build/target/wildfly-18.0.0.Final-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.dns.DnsContextFactory from [Module "org.wildfly.clustering.service" version 18.0.0.Final-SNAPSHOT from local module loader @2d3fcdbd (finder: local module finder @617c74e5 (roots: /home/jdenise/workspaces/wildfly-jfdenise/build/target/wildfly-18.0.0.Final-SNAPSHOT/modules,/home/jdenise/workspaces/wildfly-jfdenise/build/target/wildfly-18.0.0.Final-SNAPSHOT/modules/system/layers/base))]] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12631) Server doesn't start when DNS_PING is configured

by Jean Francois Denise (Jira)

Jean Francois Denise created WFLY-12631: ------------------------------------------- Summary: Server doesn't start when DNS_PING is configured Key: WFLY-12631 URL: https://issues.jboss.org/browse/WFLY-12631 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Jean Francois Denise Assignee: Paul Ferraro NPE at start. The root cause is that <module name="sun.jdk"/> is missing from org.wildfly.clustering.service module. Exception: Caused by: java.lang.NullPointerException at org.jgroups.protocols.dns.DNS_PING.destroy(DNS_PING.java:70) at java.util.ArrayList.forEach(ArrayList.java:1257) at org.jgroups.stack.ProtocolStack.destroy(ProtocolStack.java:876) at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:867) at org.jgroups.stack.ProtocolStack.init(ProtocolStack.java:849) at org.jgroups.JChannel.<init>(JChannel.java:155) at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:116) at org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.get(ChannelServiceConfigurator.java:96) Hidden exception: Failed instantiate InitialContextFactory com.sun.jndi.dns.DnsContextFactory from classloader ModuleClassLoader for Module "org.wildfly.clustering.service" version 18.0.0.Final-SNAPSHOT from local module loader @2d3fcdbd (finder: local module finder @617c74e5 (roots: /home/jdenise/workspaces/wildfly-jfdenise/build/target/wildfly-18.0.0.Final-SNAPSHOT/modules,/home/jdenise/workspaces/wildfly-jfdenise/build/target/wildfly-18.0.0.Final-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.dns.DnsContextFactory from [Module "org.wildfly.clustering.service" version 18.0.0.Final-SNAPSHOT from local module loader @2d3fcdbd (finder: local module finder @617c74e5 (roots: /home/jdenise/workspaces/wildfly-jfdenise/build/target/wildfly-18.0.0.Final-SNAPSHOT/modules,/home/jdenise/workspaces/wildfly-jfdenise/build/target/wildfly-18.0.0.Final-SNAPSHOT/modules/system/layers/base))]] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-4700) Add dependency on elytron-jwt

by Darran Lofthouse (Jira)

Darran Lofthouse created WFCORE-4700: ---------------------------------------- Summary: Add dependency on elytron-jwt Key: WFCORE-4700 URL: https://issues.jboss.org/browse/WFCORE-4700 Project: WildFly Core Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Beta1 This is only being added to Core as this is where the remaining Elytron dependencies come in - the module will be added in WildFly with the relevant subsystem. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (ELY-1884) Add new elytron-jwt module with SmallRye and MP JWT dependencies

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1884: ------------------------------------- Summary: Add new elytron-jwt module with SmallRye and MP JWT dependencies Key: ELY-1884 URL: https://issues.jboss.org/browse/ELY-1884 Project: WildFly Elytron Issue Type: Task Components: MicroProfile Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.11.0.CR1 -- 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