August 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2375) Discovery: concurrent discovery doesn't work

by Bela Ban (Jira)

Bela Ban created JGRP-2375: ------------------------------ Summary: Discovery: concurrent discovery doesn't work Key: JGRP-2375 URL: https://issues.jboss.org/browse/JGRP-2375 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.1.5 If {{num_discovery_runs}} is greater than 1, then sometimes startup of a member blocks. The stack trace below indicates this is an issue with comparison of {{Task}} ({{Future}}) elements in the ConcurrentSkipListSet. Solution: replace the set with an ArrayList: there is no need to sort the futures, or avoid duplicates, as the list is only added to or cleared. {noformat} "main" #1 prio=5 os_prio=31 tid=0x00007ff886001800 nid=0x1c03 runnable [0x000070000f96f000] java.lang.Thread.State: RUNNABLE at java.util.concurrent.ConcurrentSkipListMap.findPredecessor(ConcurrentSkipListMap.java:684) at java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:823) at java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1979) at java.util.concurrent.ConcurrentSkipListSet.add(ConcurrentSkipListSet.java:241) at org.jgroups.protocols.Discovery.findMembers(Discovery.java:235) at org.jgroups.protocols.Discovery.down(Discovery.java:380) at org.jgroups.protocols.MERGE3.down(MERGE3.java:278) at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:377) at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:235) at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:102) at org.jgroups.protocols.BARRIER.down(BARRIER.java:136) at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:553) at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:581) at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347) at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:72) at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40) at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1044) at org.jgroups.protocols.FlowControl.down(FlowControl.java:295) at org.jgroups.protocols.FlowControl.down(FlowControl.java:295) at org.jgroups.protocols.FRAG2.down(FRAG2.java:141) at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:928) at org.jgroups.JChannel.down(JChannel.java:627) at org.jgroups.JChannel._connect(JChannel.java:855) at org.jgroups.JChannel.connect(JChannel.java:352) - locked <0x000000079e04cfa0> (a org.jgroups.JChannel) at org.jgroups.JChannel.connect(JChannel.java:343) - locked <0x000000079e04cfa0> (a org.jgroups.JChannel) at org.jgroups.tests.bla6.start(bla6.java:41) at org.jgroups.tests.bla6.main(bla6.java:54) {noformat} -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4490) DMN: add a time( hour, minute, second ) alternative signature to the time() function

by Edson Tirelli (Jira)

Edson Tirelli created DROOLS-4490: ------------------------------------- Summary: DMN: add a time( hour, minute, second ) alternative signature to the time() function Key: DROOLS-4490 URL: https://issues.jboss.org/browse/DROOLS-4490 Project: Drools Issue Type: Enhancement Components: dmn engine Affects Versions: 7.26.0.Final Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 7.27.0.Final Add a built in, alternative signature to the time() function: time( hour, minute, second ) -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2344) Support UDP:PING on Quarkus

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2344?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2344: --------------------------- Fix Version/s: 4.1.5 (was: 4.1.4) > Support UDP:PING on Quarkus > --------------------------- > > Key: JGRP-2344 > URL: https://issues.jboss.org/browse/JGRP-2344 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.5 > > > Currently, {{TCP:TCPPING}} is supported. Add the {{UDP:PING}} combo. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2372) LeaveTest fails frequently

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2372?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2372: --------------------------- Fix Version/s: 4.1.5 (was: 4.1.4) > LeaveTest fails frequently > -------------------------- > > Key: JGRP-2372 > URL: https://issues.jboss.org/browse/JGRP-2372 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.5 > > > Ditto for ASYM_ENCRYPT_LeaveTest and ASYM_ENCRYPT_LeaveTestKeyExchange. Multiple members leaving seems to leave some members behind; the view is never correct. > This happens only when running the entire test suite; running a test individually, or running all encryption tests ({{ant encrypt}}) almost never reproduces the errors. > This is possibly caused by the high load of running a lot of tests concurrently, and the subsequent delays resulting from it. Nevertheless, these tests should not fail. > Error message: > {noformat} > Timeout 30000 kicked in, views are: 9: [7|15] (4) [7, 8, 9, 10] 10: [7|15] (4) [7, 8, 9, 10] > java.util.concurrent.TimeoutException > at org.jgroups.util.Util.waitUntilAllChannelsHaveSameView(Util.java:293) > at org.jgroups.tests.BaseLeaveTest.testConcurrentLeaves(BaseLeaveTest.java:189) > at org.jgroups.tests.BaseLeaveTest.testLeaveOfFirstNMembers(BaseLeaveTest.java:214) > at org.jgroups.tests.BaseLeaveTest.testLeaveOfCoordAndNext8(BaseLeaveTest.java:146) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:124) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:583) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:719) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:989) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > {noformat} -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2327) UNICAST3: create receiver table when non-first message is received first

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2327?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2327: --------------------------- Fix Version/s: 4.1.5 (was: 4.1.4) > UNICAST3: create receiver table when non-first message is received first > ------------------------------------------------------------------------ > > Key: JGRP-2327 > URL: https://issues.jboss.org/browse/JGRP-2327 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.5 > > > * A and B > * B sends 2 messages to A: B1 and B2 > * A receives B2 _before_ B1 (both B1 and B2 are OOB) > * The current code has A drop B2 and send a SEND_FIRST_SEQNO message to B > * B resends B1, but _not_ B2 > * Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered > h4. Scenario (JGRP-2293): > * A installs a new view > * B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB > * The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted > * This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs > h4. Workaround > * Set GMS.leave_timeout to a higher value (say 8000ms) > h4. Solution > * When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway > * However, this requires the first seqno from B *to always be 0* > --> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2374) TCP/TCP_NIO2: add TLS

by Bela Ban (Jira)

Bela Ban created JGRP-2374: ------------------------------ Summary: TCP/TCP_NIO2: add TLS Key: JGRP-2374 URL: https://issues.jboss.org/browse/JGRP-2374 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0 Add TLS to the TCP and TCP_NIO2 transports. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2274) ASYM_ENCRYPT: deprecate sign_msgs

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2274?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2274: -------------------------------- Yes, we can take a look at adding TLS to TCP/TCP_NIO2. I'm adding a JIRA; for 5.x as I finally want to get back to 5.x, rebase and release: https://issues.jboss.org/browse/JGRP-2374 > ASYM_ENCRYPT: deprecate sign_msgs > --------------------------------- > > Key: JGRP-2274 > URL: https://issues.jboss.org/browse/JGRP-2274 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.12 > > > In {{ASYM_ENCRYPT}}, signing messages means that the checksum of an encrypted message is computed and used together with the secret key of the sender to sign the message. On the receiver side, the public key of the sender is used to validate the signature. > However, this is redundant, as decryption of a message will fail if the contents have been changed. > If needed, signing of messages can be done in a separate protocol. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12454) [web console] not possible to configure session affinity in distributable-web subsystem

by Martin Simka (Jira)

Martin Simka created WFLY-12454: ----------------------------------- Summary: [web console] not possible to configure session affinity in distributable-web subsystem Key: WFLY-12454 URL: https://issues.jboss.org/browse/WFLY-12454 Project: WildFly Issue Type: Bug Components: Web Console Reporter: Martin Simka Assignee: Harald Pehl HAL 3.2.1 Web Console/Configuration/Subsystem/Distributable Web/HotRod/Infinispan Session It looks like it is not possible to configure session affinity. In CLI: {code} /subsystem=distributable-web/hotrod-session-management=test/affinity=local:add() {code} -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4031) Drools HACEP Operator/Ansible/Helm

by Massimiliano Dessi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4031?page=com.atlassian.jira.plugi... ] Massimiliano Dessi updated DROOLS-4031: --------------------------------------- Summary: Drools HACEP Operator/Ansible/Helm (was: Drools HACEP Operator) > Drools HACEP Operator/Ansible/Helm > ---------------------------------- > > Key: DROOLS-4031 > URL: https://issues.jboss.org/browse/DROOLS-4031 > Project: Drools > Issue Type: Task > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > Labels: HADrools > -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12453) Update wildfly-transaction-client to 1.1.7.Final

by Tomasz Adamski (Jira)

Tomasz Adamski created WFLY-12453: ------------------------------------- Summary: Update wildfly-transaction-client to 1.1.7.Final Key: WFLY-12453 URL: https://issues.jboss.org/browse/WFLY-12453 Project: WildFly Issue Type: Component Upgrade Components: Transactions Affects Versions: 17.0.1.Final Reporter: Tomasz Adamski Assignee: Tomasz Adamski Fix For: 18.0.0.Final -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 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 August 2019