June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (HAWKULARQE-7) [QE] - JMAN4-160 - OpenShift EAP 6 Docker image with Hawkular Agent

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-7?page=com.atlassian.jira.plug... ] Hayk Hovsepyan commented on HAWKULARQE-7: ----------------------------------------- Blocker BZ is verified. > [QE] - JMAN4-160 - OpenShift EAP 6 Docker image with Hawkular Agent > ------------------------------------------------------------------- > > Key: HAWKULARQE-7 > URL: https://issues.jboss.org/browse/HAWKULARQE-7 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Blocker > Labels: mm-integration-hawkular-qe > > See [JMAN4-160|https://issues.jboss.org/browse/JMAN4-160] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2191) (7.0.z) COUNTER does not work with ForkChannel on an already connected main channel

by Bartosz Spyrko-Śmietanko (JIRA)

Bartosz Spyrko-Śmietanko created JGRP-2191: ---------------------------------------------- Summary: (7.0.z) COUNTER does not work with ForkChannel on an already connected main channel Key: JGRP-2191 URL: https://issues.jboss.org/browse/JGRP-2191 Project: JGroups Issue Type: Bug Reporter: Bartosz Spyrko-Śmietanko Assignee: Bela Ban Fix For: 4.0, 3.6.13 The following code doesn't work: {code:java} JChannel ch=new JChannel().connect("cluster"); ForkChannel fc=new ForkChannel(ch, "counter-stack", "counter-channel", true, ProtocolStack.Position.ABOVE, FRAG2.class, new COUNTER()); CounterService counter_service=new CounterService(fc); fc.connect("ignore"); Counter counter=counter_service.getOrCreateCounter("cntr", 0); {code} Method {{getOrCreateCounter()}} hangs as its coord is null because it didn't get a view change. The issue is that COUNTER only processes view changes sent from below but not from above. The former happens when the main channel is connected, the latter when ForkChannel.connect() is called. SOLUTION: add view change processing in down(). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2190) (7.0.z) Encrypt protocols transform empty buffer into null buffer when encrypt_entire_message is disabled

by Bartosz Spyrko-Śmietanko (JIRA)

Bartosz Spyrko-Śmietanko created JGRP-2190: ---------------------------------------------- Summary: (7.0.z) Encrypt protocols transform empty buffer into null buffer when encrypt_entire_message is disabled Key: JGRP-2190 URL: https://issues.jboss.org/browse/JGRP-2190 Project: JGroups Issue Type: Bug Affects Versions: 3.6.12 Reporter: Bartosz Spyrko-Śmietanko Assignee: Bela Ban Priority: Critical Fix For: 4.0, 3.6.13 This causes an NPEs in WildFly where empty buffers have significance (i.e. to indicate an unknown fork channel). See the pull request \[1\] for a discussion of the proposed fix. \[1\] https://github.com/belaban/JGroups/pull/340 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2189) (7.0.z) SYM_ENCRYPT: allow other keystore types besides JCEKS

by Bartosz Spyrko-Śmietanko (JIRA)

Bartosz Spyrko-Śmietanko created JGRP-2189: ---------------------------------------------- Summary: (7.0.z) SYM_ENCRYPT: allow other keystore types besides JCEKS Key: JGRP-2189 URL: https://issues.jboss.org/browse/JGRP-2189 Project: JGroups Issue Type: Feature Request Reporter: Bartosz Spyrko-Śmietanko Assignee: Bela Ban Fix For: 4.0, 3.6.13 Currently SYM_ENCRYPT accepts only keystores of type JCEKS. Other types such as JKS or PKCS12 are not permitted. Solution: add an attribute keystore_type to SYM_ENCRYPT, which will allow for other keystore types to be used. E.g. keystore_type="PKCS12" means that an external certificate generated by openssl will be usable. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2188) (7.0.z) FD_HOST doesn't print stack trace

by Bartosz Spyrko-Śmietanko (JIRA)

Bartosz Spyrko-Śmietanko created JGRP-2188: ---------------------------------------------- Summary: (7.0.z) FD_HOST doesn't print stack trace Key: JGRP-2188 URL: https://issues.jboss.org/browse/JGRP-2188 Project: JGroups Issue Type: Bug Reporter: Bartosz Spyrko-Śmietanko Assignee: Osamu Nagano Priority: Minor Fix For: 3.6.12, 4.0 Something happened in {{FD_HOST}} but a stack trace is omitted, which could have a clue to the root cause. {code} 2016-11-02 15:55:49,738 SEVERE [org.jgroups.protocols.FD_HOST] (Timer-2,node331-53459) node331-53459: ping command failed: java.lang.NullPointerException {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2187) (7.0.z) Request.viewChange() implementations should not use View.getMembers()

by Bartosz Spyrko-Śmietanko (JIRA)

Bartosz Spyrko-Śmietanko created JGRP-2187: ---------------------------------------------- Summary: (7.0.z) Request.viewChange() implementations should not use View.getMembers() Key: JGRP-2187 URL: https://issues.jboss.org/browse/JGRP-2187 Project: JGroups Issue Type: Bug Reporter: Bartosz Spyrko-Śmietanko Assignee: Bela Ban Priority: Minor Fix For: 3.6.12, 4.0 {{Request.viewChange()}} is called once for every request, and {{View.getMembers()}} allocates 2 (small) objects. Both {{UnicastRequest}} and {{GroupRequest}} could use {{View.containsMember()}} instead. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8879) Verify that all tests disabled by DisableInvocationTestUtil were re-enabled

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-8879?page=com.atlassian.jira.plugin.... ] Farah Juma moved JBEAP-11324 to WFLY-8879: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8879 (was: JBEAP-11324) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security Test Suite (was: Security) (was: Test Suite) Affects Version/s: (was: 7.1.0.DR12) > Verify that all tests disabled by DisableInvocationTestUtil were re-enabled > --------------------------------------------------------------------------- > > Key: WFLY-8879 > URL: https://issues.jboss.org/browse/WFLY-8879 > Project: WildFly > Issue Type: Task > Components: Security, Test Suite > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Blocker > > As a part of https://issues.jboss.org/browse/EAP7-643 works, problematic test cases were skipped by {{DisableInvocationTestUtil.disable()}} invocation. Since we do not track each Test case separately, we should make sure that all tests were re-enabled in order not to lose any test coverage. > DR12 status: > jboss-eap-7.1-src]$ grep -lr 'DisableInvocationTestUtil.disable()' | wc -l > 54 > See [^disable_list_dr12] for complete lest of problematic test cases. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2186) (7.0.z) UNICAST3 drops all messages until it receives the first one

by Bartosz Spyrko-Śmietanko (JIRA)

Bartosz Spyrko-Śmietanko created JGRP-2186: ---------------------------------------------- Summary: (7.0.z) UNICAST3 drops all messages until it receives the first one Key: JGRP-2186 URL: https://issues.jboss.org/browse/JGRP-2186 Project: JGroups Issue Type: Bug Affects Versions: 3.6.10 Reporter: Bartosz Spyrko-Śmietanko Assignee: Bela Ban Fix For: 3.6.12, 4.0 UNICAST3.getReceiverEntry returns null if it hasn't seen the first message yet. This causes UNICAST3.handleDataReceived to drop the message. When you add *ENCRYPT, this causes a major deadlock. *ENCRYPT will queue most messages until it gets the encryption key, which can often include the first message (so UNICAST3 won't see it yet). Then when an important message such as JOIN_RSP comes through, UNICAST3 drops it. Since UNICAST3 never lets any messages through in this case, the encryption key will never get set so that *ENCRYPT can pass the first message up and free the deadlock. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2185) (7.0.z) Headers.resize() called unnecessarily

by Bartosz Spyrko-Śmietanko (JIRA)

Bartosz Spyrko-Śmietanko created JGRP-2185: ---------------------------------------------- Summary: (7.0.z) Headers.resize() called unnecessarily Key: JGRP-2185 URL: https://issues.jboss.org/browse/JGRP-2185 Project: JGroups Issue Type: Bug Reporter: Bartosz Spyrko-Śmietanko Assignee: Bela Ban Priority: Minor Fix For: 3.6.12, 4.0 Each message has space for 4 headers. When a 5th header needs to be added, the array needs to be resized. This is something we want to avoid as much as possible. However, the following scenario can lead to resizing: * A bundler writes a message list with (say) 3 headers * A message list always ignores the transport header, as it is only used to carry the cluster name, but that name is available in the batch header, too. * Therefore, the size of the headers written is 2 and the transport header is not written * On the receiver side, when reading the batch, we create and read 2 headers ** This is OK, as message batches are matched against the receiver's cluster name using the cluster name shipped in the batch itself and not in the message ** Message batches are therefore passed up without the individual messages carrying a transport header * However, single messages need to carry a transport header as it will be used to do the cluster name matching * Now, if a batch contains messages tagged as {{OOB|DONT_BUNDLE}}, they will be removed from the batch and sent up the stack as separate messages, each in a separate thread. * To do this, each of these messages is added a transport header (created using the batch's cluster name). * However, this necessitates a resizing as the headers array has a length of only 2, but we now need 3 headers Note that we don't run into this in 4.0, as Infinispan 9 (which uses 4) doesn't use {{DONT_BUNDLE}} any longer. It is still an unnecessary memory allocation and needs to be optimized. However, we should fix it in 3.6 as we still use {{DONT_BUNDLE}} in Infinispan 8. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2184) (7.0.z) Sticky site masters

by Bartosz Spyrko-Śmietanko (JIRA)

Bartosz Spyrko-Śmietanko created JGRP-2184: ---------------------------------------------- Summary: (7.0.z) Sticky site masters Key: JGRP-2184 URL: https://issues.jboss.org/browse/JGRP-2184 Project: JGroups Issue Type: Feature Request Reporter: Bartosz Spyrko-Śmietanko Assignee: Bela Ban Fix For: 3.6.12, 4.0 If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur. Example: * Member C in site LON sends messages C1 and C2 to site NYC * C1 picks SM1 and C2 picks SM2 * Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues h4. Design * When sending a message to the one of the site masters of the current site, or from a site master to a remote site master, we invoke a callback to pick the site master based on the original caller * Note that this only applies when we have more than one site master. * The callback passes the address of the original caller and the list of available site masters, and needs to return a site master h5. Transactions * Transactions by different originators with overlapping key sets cannot be reliably ordered * Transactional support therefore requires single site masters * This should not be an issue as transactions bundle multiple updates, so the number of messages sent is less than non-transactional updates -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 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 June 2017