February 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3608) Wrong behavior with top level collection in DMN scenario

by Daniele Zonca (Jira)

Daniele Zonca created DROOLS-3608: ------------------------------------- Summary: Wrong behavior with top level collection in DMN scenario Key: DROOLS-3608 URL: https://issues.jboss.org/browse/DROOLS-3608 Project: Drools Issue Type: Bug Components: Scenario Simulation and Testing Reporter: Daniele Zonca Assignee: Daniele Zonca Attachments: dmn-list.dmn If you have a DMN file with a top level collection like a list of string not as field of a complex object but as top level. The type is not correctly loaded and managed. See dmn-list.dmn as example -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2305) Get rid of need for java.net.preferIPv4Stack

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/JGRP-2305?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on JGRP-2305: ------------------------------------ Not sure if I should reopen this issue, but I can only run tests that use MPING with the default settings (e.g. {{LeaveTest}}) if I set {{-Djava.net.preferIPv4Stack=true}}. Without it I get this error: {noformat} 17:00:31,730 ERROR (main:[]) [MPING] JGRP000200: failed sending discovery request java.io.IOException: Invalid argument (sendto failed) at java.net.PlainDatagramSocketImpl.send(Native Method) ~[?:1.8.0_171] at java.net.DatagramSocket.send(DatagramSocket.java:693) ~[?:1.8.0_171] at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:306) [classes/:?] at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:64) [classes/:?] at org.jgroups.protocols.PING.findMembers(PING.java:32) [classes/:?] at org.jgroups.protocols.Discovery.invokeFindMembers(Discovery.java:214) [classes/:?] at org.jgroups.protocols.Discovery.findMembers(Discovery.java:239) [classes/:?] at org.jgroups.protocols.Discovery.down(Discovery.java:379) [classes/:?] at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:376) [classes/:?] at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:236) [classes/:?] at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:101) [classes/:?] at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:563) [classes/:?] at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:570) [classes/:?] at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:346) [classes/:?] at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:72) [classes/:?] at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40) [classes/:?] at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1076) [classes/:?] at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:908) [classes/:?] at org.jgroups.JChannel.down(JChannel.java:668) [classes/:?] at org.jgroups.JChannel._connect(JChannel.java:897) [classes/:?] at org.jgroups.JChannel.connect(JChannel.java:393) [classes/:?] at org.jgroups.JChannel.connect(JChannel.java:384) [classes/:?] at org.jgroups.tests.LeaveTest.setup(LeaveTest.java:48) [classes/:?] at org.jgroups.tests.LeaveTest.testConcurrentLeaves2(LeaveTest.java:152) [classes/:?] {noformat} > Get rid of need for java.net.preferIPv4Stack > -------------------------------------------- > > Key: JGRP-2305 > URL: https://issues.jboss.org/browse/JGRP-2305 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.16 > > > New address picking scheme: > * First we detect which addresses are available: IPv4 and/or IPv6 (dual-stack if both) > * When we encounter an IPv4 address: > ** If dual-stack or IPv4 stack: use it > ** If IPv6-only stack: use it unless it is a class D (multicast) address: then convert it to an IPv6-mapped address > * When we encounter an IPv6 address: > ** If dual-stack or IPv6-only stack: use it > ** Else: throw an exception (IPv6 address in an IPv4-only stack) -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2293) Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2293?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2293: -------------------------------- Do you have {{java.net.preferIPv4Stack=true}} set in IntelliJ? > Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views > --------------------------------------------------------------------------------- > > Key: JGRP-2293 > URL: https://issues.jboss.org/browse/JGRP-2293 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.14 > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Critical > Fix For: 4.0.17 > > Attachments: IMG_20190123_124154.jpg > > > JGroups does not handle concurrent leaving of nodes correctly. This is a typical use case in cloud environment when scaled down with an autoscaler/manually which we need to handle. > A simple test can be devised which fails first n (where n>1) nodes from a cluster, reproducer PR https://github.com/belaban/JGroups/pull/397 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2293) Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/JGRP-2293?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on JGRP-2293: ------------------------------------ Yes, either of these make the test work from Maven: {code} mping.setBindAddr(InetAddress.getByName("wlan ip")); or mping.setMcastAddr(InetAddress.getByName("225.5.5.5")); {code} I'm still baffled why the test works unchanged in IntelliJ: like I said, it uses exactly the same bind/mcast addresses. > Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views > --------------------------------------------------------------------------------- > > Key: JGRP-2293 > URL: https://issues.jboss.org/browse/JGRP-2293 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.14 > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Critical > Fix For: 4.0.17 > > Attachments: IMG_20190123_124154.jpg > > > JGroups does not handle concurrent leaving of nodes correctly. This is a typical use case in cloud environment when scaled down with an autoscaler/manually which we need to handle. > A simple test can be devised which fails first n (where n>1) nodes from a cluster, reproducer PR https://github.com/belaban/JGroups/pull/397 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2329) FD_SOCK NullPointerException during shutdown

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2329?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2329. ---------------------------- Resolution: Done > FD_SOCK NullPointerException during shutdown > -------------------------------------------- > > Key: JGRP-2329 > URL: https://issues.jboss.org/browse/JGRP-2329 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.16 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.17 > > > {noformat} > "FD_SOCK acceptor-11,LeaveTest,1@5864" daemon prio=5 tid=0x885 nid=NA runnable > java.lang.Thread.State: RUNNABLE > at java.lang.NullPointerException.<init>(NullPointerException.java:60) > at org.jgroups.protocols.FD_SOCK$ServerSocketHandler.run(FD_SOCK.java:996) > at java.lang.Thread.run(Thread.java:748) > "main@1" prio=5 tid=0x1 nid=NA waiting > java.lang.Thread.State: WAITING > at java.lang.Object.wait(Object.java:-1) > at java.lang.Thread.join(Thread.java:1260) > at org.jgroups.protocols.FD_SOCK.stopPingerThread(FD_SOCK.java:544) > - locked <0x1858> (a org.jgroups.protocols.FD_SOCK) > at org.jgroups.protocols.FD_SOCK.stop(FD_SOCK.java:218) > at org.jgroups.stack.ProtocolStack.removeProtocol(ProtocolStack.java:692) > at org.jgroups.stack.ProtocolStack.removeProtocol(ProtocolStack.java:678) > at org.jgroups.stack.ProtocolStack.removeProtocols(ProtocolStack.java:659) > at org.jgroups.tests.LeaveTest.lambda$testLeaveOfSecondHalfWithCoordLeaving$6(LeaveTest.java:134) > {noformat} > The exception is not caught, so it's only logged to stderr by the default uncaught exception handler. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1713) Restore Javadoc Generation

by Diana Vilkolakova (Jira)

[ https://issues.jboss.org/browse/ELY-1713?page=com.atlassian.jira.plugin.s... ] Diana Vilkolakova updated ELY-1713: ----------------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/1227, https://github.com/wildfly-security-incubator/wildfly-elytron/pull/72 (was: https://github.com/wildfly-security-incubator/wildfly-elytron/pull/72) > Restore Javadoc Generation > -------------------------- > > Key: ELY-1713 > URL: https://issues.jboss.org/browse/ELY-1713 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Assignee: Diana Vilkolakova > Priority: Critical > Fix For: 1.9.0.CR1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1738) Clean up the 'wildfly-elytron-http' module as it currently contains both public and private API

by Diana Vilkolakova (Jira)

[ https://issues.jboss.org/browse/ELY-1738?page=com.atlassian.jira.plugin.s... ] Diana Vilkolakova updated ELY-1738: ----------------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/1228, https://github.com/wildfly-security-incubator/wildfly-elytron/pull/79 (was: https://github.com/wildfly-security-incubator/wildfly-elytron/pull/79) > Clean up the 'wildfly-elytron-http' module as it currently contains both public and private API > ----------------------------------------------------------------------------------------------- > > Key: ELY-1738 > URL: https://issues.jboss.org/browse/ELY-1738 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Assignee: Diana Vilkolakova > Priority: Major > Fix For: 2.0.0.Alpha1, 1.9.0.CR1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2329) FD_SOCK NullPointerException during shutdown

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2329?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2329: --------------------------- Fix Version/s: 4.0.17 > FD_SOCK NullPointerException during shutdown > -------------------------------------------- > > Key: JGRP-2329 > URL: https://issues.jboss.org/browse/JGRP-2329 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.16 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.17 > > > {noformat} > "FD_SOCK acceptor-11,LeaveTest,1@5864" daemon prio=5 tid=0x885 nid=NA runnable > java.lang.Thread.State: RUNNABLE > at java.lang.NullPointerException.<init>(NullPointerException.java:60) > at org.jgroups.protocols.FD_SOCK$ServerSocketHandler.run(FD_SOCK.java:996) > at java.lang.Thread.run(Thread.java:748) > "main@1" prio=5 tid=0x1 nid=NA waiting > java.lang.Thread.State: WAITING > at java.lang.Object.wait(Object.java:-1) > at java.lang.Thread.join(Thread.java:1260) > at org.jgroups.protocols.FD_SOCK.stopPingerThread(FD_SOCK.java:544) > - locked <0x1858> (a org.jgroups.protocols.FD_SOCK) > at org.jgroups.protocols.FD_SOCK.stop(FD_SOCK.java:218) > at org.jgroups.stack.ProtocolStack.removeProtocol(ProtocolStack.java:692) > at org.jgroups.stack.ProtocolStack.removeProtocol(ProtocolStack.java:678) > at org.jgroups.stack.ProtocolStack.removeProtocols(ProtocolStack.java:659) > at org.jgroups.tests.LeaveTest.lambda$testLeaveOfSecondHalfWithCoordLeaving$6(LeaveTest.java:134) > {noformat} > The exception is not caught, so it's only logged to stderr by the default uncaught exception handler. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2329) FD_SOCK NullPointerException during shutdown

by Dan Berindei (Jira)

Dan Berindei created JGRP-2329: ---------------------------------- Summary: FD_SOCK NullPointerException during shutdown Key: JGRP-2329 URL: https://issues.jboss.org/browse/JGRP-2329 Project: JGroups Issue Type: Bug Affects Versions: 4.0.16 Reporter: Dan Berindei Assignee: Bela Ban {noformat} "FD_SOCK acceptor-11,LeaveTest,1@5864" daemon prio=5 tid=0x885 nid=NA runnable java.lang.Thread.State: RUNNABLE at java.lang.NullPointerException.<init>(NullPointerException.java:60) at org.jgroups.protocols.FD_SOCK$ServerSocketHandler.run(FD_SOCK.java:996) at java.lang.Thread.run(Thread.java:748) "main@1" prio=5 tid=0x1 nid=NA waiting java.lang.Thread.State: WAITING at java.lang.Object.wait(Object.java:-1) at java.lang.Thread.join(Thread.java:1260) at org.jgroups.protocols.FD_SOCK.stopPingerThread(FD_SOCK.java:544) - locked <0x1858> (a org.jgroups.protocols.FD_SOCK) at org.jgroups.protocols.FD_SOCK.stop(FD_SOCK.java:218) at org.jgroups.stack.ProtocolStack.removeProtocol(ProtocolStack.java:692) at org.jgroups.stack.ProtocolStack.removeProtocol(ProtocolStack.java:678) at org.jgroups.stack.ProtocolStack.removeProtocols(ProtocolStack.java:659) at org.jgroups.tests.LeaveTest.lambda$testLeaveOfSecondHalfWithCoordLeaving$6(LeaveTest.java:134) {noformat} The exception is not caught, so it's only logged to stderr by the default uncaught exception handler. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3607) Beans annotated with @propertyChangeSupport don't take count of property reactvity when propagating a modification

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3607?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-3607. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/339805035b2883e6b1ba72099a99021... > Beans annotated with @propertyChangeSupport don't take count of property reactvity when propagating a modification > ------------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-3607 > URL: https://issues.jboss.org/browse/DROOLS-3607 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

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