March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4368) Remove the org.apache.commons:commons-lang3 exclusion from elytron-tool

by Kabir Khan (Jira)

[ https://issues.jboss.org/browse/WFCORE-4368?page=com.atlassian.jira.plugi... ] Kabir Khan commented on WFCORE-4368: ------------------------------------ [~dlofthouse] A 'version convergence error' (or whatever it is called) by the enforcer plugin. See https://issues.apache.org/jira/browse/MENFORCER-195 linked in the main issue. > Remove the org.apache.commons:commons-lang3 exclusion from elytron-tool > ----------------------------------------------------------------------- > > Key: WFCORE-4368 > URL: https://issues.jboss.org/browse/WFCORE-4368 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Kabir Khan > Priority: Major > > See https://issues.jboss.org/browse/WFCORE-4366 for details of why it is needed. Since the Elytron tool shades all its dependencies, can they have a scope which does not get exported again? Perhaps provided, although I don't know if those work with the shade plugin. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2333) pbcast.GMS#getView returns ViewId as opposed to the View

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2333?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2333: --------------------------- Fix Version/s: 4.1.1 (was: 4.0.20) > pbcast.GMS#getView returns ViewId as opposed to the View > -------------------------------------------------------- > > Key: JGRP-2333 > URL: https://issues.jboss.org/browse/JGRP-2333 > Project: JGroups > Issue Type: Bug > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 4.1.1 > > > Basically org.jgroups.protocols.pbcast.GMS#getView is now identical to org.jgroups.protocols.pbcast.GMS#getViewId while the intention is to be able to see the current view. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2303) RELAY2: notification when a site is up/down on all cluster nodes

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2303?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2303: --------------------------- Fix Version/s: 4.1.1 (was: 4.0.20) > RELAY2: notification when a site is up/down on all cluster nodes > ---------------------------------------------------------------- > > Key: JGRP-2303 > URL: https://issues.jboss.org/browse/JGRP-2303 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.1.1 > > > Provide a callback that's invoked on *all nodes* when a site is up/down, and possibly an initial view of the sites. Could be something like a 'sites view', e.g. \{"LON", "SFO"\}, \{"LON"\}, \{"LON", "SFO", "NYC\} etc -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2320) FILE_PING.findMembers() optimizations

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2320?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2320: --------------------------- Fix Version/s: 4.1.1 (was: 4.0.20) > FILE_PING.findMembers() optimizations > ------------------------------------- > > Key: JGRP-2320 > URL: https://issues.jboss.org/browse/JGRP-2320 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.16, 4.0.15 > Reporter: Nick Sawadsky > Assignee: Bela Ban > Priority: Minor > Fix For: 4.1.1 > > > Following on from JGRP-2288, a couple of possible optimizations/improvements to {{FILE_PING.findMembers()}} were identified. > 1. After the initial call to {{readAll()}}, some corrective steps are taken if the local node address was not returned by {{readAll()}}. However, in the case where {{findMembers()}} is invoked by {{TP.fetchResponsesFromDiscoveryProtocol()}}, it is normal if the local node address is not returned, since the {{readAll()}} responses are filtered based on the {{members}} parameter. > To avoid unnecessary writes to the file or cloud store, it would be good to add some checks based on whether {{members}} is null or not. For example, the calls to {{write()}} and {{writeAll()}} should probably not occur unless {{members}} is null. > 2. In the call to {{sendDiscoveryResponse()}}, the last parameter is always {{false}}. However, it seems possible for a coordinator to get to this point in some edge cases. Though I haven't been able to identify any clear bugs that this would lead to, it might be better to pass {{is_coord}} as the last parameter. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2331) Probe does not handle multiple protocols of the same class in the same stack

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2331?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2331: --------------------------- Fix Version/s: 4.1.1 (was: 4.0.20) > Probe does not handle multiple protocols of the same class in the same stack > ---------------------------------------------------------------------------- > > Key: JGRP-2331 > URL: https://issues.jboss.org/browse/JGRP-2331 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Optional > Fix For: 4.1.1 > > > When we have multiple protocols of the same type (e.g. FRAG2) in the same stack, probe.sh only dumps information about the first one found. E.g. in > {noformat} > <UDP/> > <PING/> > <FRAG2 id="350".../> > ... > <GMS/> > <FRAG2.../> > {noformat} > , the FRAG2 protocol with id 350 would likely get skipped as the other one was found first in a query like {{probe.sh jmx=FRAG2}} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

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.1 (was: 4.0.20) > 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.1 > > > * 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.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2299: --------------------------- Fix Version/s: 4.1.1 (was: 4.0.20) > LockService does not work correctly if unlock/lock is called in immediate succession > ------------------------------------------------------------------------------------ > > Key: JGRP-2299 > URL: https://issues.jboss.org/browse/JGRP-2299 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.15 > Environment: Windows 10 Oracle JDK 1.8 131 > AIX IBM Java 8 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.1 > > Attachments: JGroupsExample.java, udp+lock.xml > > > In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected. > This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded. > If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock(). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2284) Discovery protocol for members in the same process

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2284?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2284: --------------------------- Fix Version/s: 4.1.1 (was: 4.0.20) > Discovery protocol for members in the same process > -------------------------------------------------- > > Key: JGRP-2284 > URL: https://issues.jboss.org/browse/JGRP-2284 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.1 > > > Discovery protocol that works for members in the same process. Something like SHARED_LOOPBACK_PING, but without the requirement for SHARED_LOOPBACK as transport, but it should work over UDP, TCP, TCP_NIO2 etc. > Similar to TEST_PING in Infinispan. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2311) tshark/wireshark support

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2311?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2311: --------------------------- Fix Version/s: 4.1.1 (was: 4.0.20) > tshark/wireshark support > ------------------------ > > Key: JGRP-2311 > URL: https://issues.jboss.org/browse/JGRP-2311 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.1 > > Attachments: tshark-convert.py > > > 1. Dump contents of wireshark/tahsrk/tcpdump-generated (PCAP) files (using {{ParseMessages}} > 2. Do this dynamically, e.g. `tshark -Tfields -e data` | java ParseMessages > In the second instantiation, ParseMessages would read packets from stdin. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2318) KUBE_PING: test with RBAC

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2318?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2318: --------------------------- Fix Version/s: 4.1.1 (was: 4.0.20) > KUBE_PING: test with RBAC > ------------------------- > > Key: JGRP-2318 > URL: https://issues.jboss.org/browse/JGRP-2318 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.1.1 > > > Test if KUBE_PING still works with the latest minikube/RBAC combo -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

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