March 2019 - jboss-jira - Jboss List Archives

[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.0.20 (was: 4.0.19) > 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.0.20 > > > * 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)

5 years, 10 months

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.0.20 (was: 4.0.19) > 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.0.20 > > > 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)

5 years, 10 months

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.0.20 (was: 4.0.19) > 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.0.20 > > > 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)

5 years, 10 months

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.0.20 (was: 4.0.19) > 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.0.20 > > > 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)

5 years, 10 months

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.0.20 (was: 4.0.19) > 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.0.20 > > 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)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2310) SubstrateVM

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2310?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2310: --------------------------- Fix Version/s: 4.0.20 (was: 4.0.19) > SubstrateVM > ----------- > > Key: JGRP-2310 > URL: https://issues.jboss.org/browse/JGRP-2310 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.20 > > > Compile JGroups to run with SubstrateVM and run (e.g.) Draw with it -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2283) Lock race condition

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2283?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2283: --------------------------- Fix Version/s: 4.0.20 (was: 4.0.19) > Lock race condition > ------------------- > > Key: JGRP-2283 > URL: https://issues.jboss.org/browse/JGRP-2283 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.20 > > Attachments: RDBXGNBM.txt, m1PNLdDr.txt > > > The attached program fails to run repeats of tryLock-unlock sequences. > Program and config are attached -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

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.0.20 (was: 4.0.19) > 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.0.20 > > > 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)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2297) Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2297?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2297. ---------------------------- Resolution: Done > Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully > -------------------------------------------------------------------- > > Key: JGRP-2297 > URL: https://issues.jboss.org/browse/JGRP-2297 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.14 > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Blocker > Fix For: 4.0.19 > > > The {{ASYM_ENCRYPT_LeaveTest}} is designed to test graceful leaving coordinator(s) with ASYM_ENCRYPT in the stack. However, the test currently passes due to presence of MERGE3 in the stack. While the intention of the test seems to be testing graceful leaving of coordinator(s), the cluster ends up with inconsistent views later resolved by MERGE3. > Here is a run of the test with a modification of the test with a *single* coordinator leaving: > https://gist.github.com/rhusar/89172882fae60a1f29327c33f2d124db > The problem seems to be with coordinating of key exchange. In this run, roughly: > 1. node 1 is leaving > 2. node 2 becomes coordinator and key server > {noformat} > 10:55:18.286 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: installing view [2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10] > ... > 10:55:18.299 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: I'm the new key server > 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85) > ... > 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85) > {noformat} > 3. node 9 receives {{FETCH_SECRET_KEY}} however receives stale key? looks like it still contacts the leaving coordinator node 1? > {noformat} > 10:55:18.319 [SSL_KEY_EXCHANGE-runner-12,ASYM_ENCRYPT_LeaveTest,1] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 1: accepted SSL connection from /127.0.0.1:51812; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA > ... > 10:55:18.319 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2157); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA > 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AF7916A9394F49B085D4F35C4F5A0A3E) > 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: ignoring secret key received from key exchange protocol (version: AF7916A9394F49B085D4F35C4F5A0A3E), as it has already been installed > {noformat} > 4. new coordinator fails to collect all acks (since it cannot decipher stale key?) > {noformat} > 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] WARN org.jgroups.protocols.pbcast.GMS - 2: failed to collect all ACKs (expected=8) for view [2|10] after 2000ms, missing 1 ACKs from (1) 9 > {noformat} > 5. node 9 eventually obtains the key but since it has stale view and still thinks node 1 is coordinator? and fails to contact it > {noformat} > 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: asking key exchange protocol to get secret key from 2 > 10:55:20.322 [SSL_KEY_EXCHANGE-runner-26,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 2: accepted SSL connection from /127.0.0.1:51829; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA > 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2158); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA > 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AB1E6F44DE947D792A7D05D2E957AC85) > 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: installing secret key received from key exchange protocol (version: AB1E6F44DE947D792A7D05D2E957AC85) > 10:55:23.341 [TQ-Bundler-10,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.TCP - JGRP000034: 9: failure sending message to 1: java.net.ConnectException: Connection refused (Connection refused) > {noformat} > 6. cluster is later healed with MERGE3 > {noformat} > 10:55:27.103 [jgroups-27,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: I will be the merge leader. Starting the merge task. Views: {2=[2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10], 9=[1|9] (10) [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]} > {noformat} > Another run with MERGE3 omitted from the stack is here: > https://gist.github.com/rhusar/b51aeee03485a607041f9669bbc6e707 > Further investigation is ongoing, but this might be related to graceful leaving of coordinator JGRP-2293 exacerbating the problem with key exchange in ASYM_ENCRYPT. > Scaling down is typical cloud workflow, especially with encryption since {{ASYM_ENCRYPT}} is the recommended setup making this problem critical. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8136) allow JAX-RS @Produces in CDI @Stereotype

by Marek Kopecký (Jira)

[ https://issues.jboss.org/browse/WFLY-8136?page=com.atlassian.jira.plugin.... ] Marek Kopecký commented on WFLY-8136: ------------------------------------- There is currently no clear plan for the target release of this feature request. > allow JAX-RS @Produces in CDI @Stereotype > ----------------------------------------- > > Key: WFLY-8136 > URL: https://issues.jboss.org/browse/WFLY-8136 > Project: WildFly > Issue Type: Feature Request > Components: CDI / Weld, REST > Affects Versions: 9.0.1.Final, 15.0.0.Final > Environment: Windows 7, JDK 1.8.0_60 > Reporter: Andreas Klemp > Assignee: Martin Stefanko > Priority: Major > > A simple JAX-RS REST service can be annotated with @Produces to define the resulting mime-type. However, it is not working anymore, when the annotation is moved to a stereotype. The default application/octet-stream is used. > {code} > @Stereotype > @Produces(MediaType.APPLICATION_JSON) > @Target(ElementType.TYPE) > @Retention(RetentionPolicy.RUNTIME) > public @interface RestService { > } > @Path("/some") > @RestService > public class SomeRestService { > @GET > @Path("/") > public Response getSome() { > return Response.ok().entity("{\"x\" : 42, \"y\" : \"foo\"}").build(); > } > } > {code} > Using the following dependencies in Gradle project. > {noformat} > providedCompile( > [group: 'javax.enterprise', name: 'cdi-api', version: '1.2'], > [group: 'org.jboss.spec.javax.ws.rs', name: 'jboss-jaxrs-api_2.0_spec', version: '1.0.0.Final'], > [group: 'com.fasterxml.jackson.core', name: 'jackson-databind', version: '2.7.4'] > ) > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2019