June 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10555) The list-messages and remove-messages don't work on a queue when consumer is connected

by Josef Cacek (JIRA)

Josef Cacek created WFLY-10555: ---------------------------------- Summary: The list-messages and remove-messages don't work on a queue when consumer is connected Key: WFLY-10555 URL: https://issues.jboss.org/browse/WFLY-10555 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 13.0.0.Final, 11.0.0.Final Reporter: Josef Cacek Assignee: Jeff Mesnil Attachments: helloworld-jms.zip The queue operations {{:list-messages}} and {{:remove-messages}} don't work (return empty set) if a consumer is attached to the server. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10554) OpenSAML 3.3.0 complains for missing class from "metrics-core"

by Radoslav Ivanov (JIRA)

Radoslav Ivanov created WFLY-10554: -------------------------------------- Summary: OpenSAML 3.3.0 complains for missing class from "metrics-core" Key: WFLY-10554 URL: https://issues.jboss.org/browse/WFLY-10554 Project: WildFly Issue Type: Bug Components: Security Affects Versions: 13.0.0.Final Reporter: Radoslav Ivanov Assignee: Darran Lofthouse Priority: Critical Module OpenSAML 3.3.0 requires depedency to module "io.dropwizard.metrics:metrics-core" but it does not present. As a result ClassNotFoundException is thrown. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-288) Kiali - Istio Checker to 0.8.0

by Sunil kondkar (JIRA)

[ https://issues.jboss.org/browse/SWSQE-288?page=com.atlassian.jira.plugin.... ] Sunil kondkar reassigned SWSQE-288: ----------------------------------- Assignee: Sunil kondkar (was: Matt Mahoney) > Kiali - Istio Checker to 0.8.0 > ------------------------------ > > Key: SWSQE-288 > URL: https://issues.jboss.org/browse/SWSQE-288 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Sunil kondkar > > We have a job http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Kiali-Istio-Checker > which checks Istio installation on OC. It works with 0.7.1 Istio. > Main jenkins pipeline is switched to Istio 0.8.0 already. > TODO > Update this job and the script to support Istio 0.8.0 version pods which are: > grafana-cd99bf478-2k9zj 1/1 Running 0 19m > istio-citadel-ff5696f6f-6m8rv 1/1 Running 0 19m > istio-cleanup-old-ca-qmd7k 0/1 Completed 0 19m > istio-egressgateway-58d98d898c-4qhx9 0/1 CrashLoopBackOff 7 19m > istio-ingressgateway-6bc7c7c4bc-867sz 0/1 CrashLoopBackOff 7 19m > istio-mixer-post-install-kjhhk 0/1 Completed 0 19m > istio-pilot-6c5c6b586c-gq6gt 2/2 Running 0 19m > istio-policy-5c7fbb4b9f-j2jjd 2/2 Running 0 19m > istio-sidecar-injector-dbd67c88d-ffkgm 1/1 Running 0 19m > istio-statsd-prom-bridge-6dbb7dcc7f-fcl8f 1/1 Running 0 19m > istio-telemetry-54b5bf4847-5wq78 2/2 Running 0 19m > istio-tracing-67dbb5b89f-l52vk 1/1 Running 0 19m > prometheus-586d95b8d9-dw9xl 1/1 Running 0 19m > servicegraph-6d86dfc6cb-25qtp 1/1 Running 1 19m -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-46) Build SWS project CI pipeline on Openshif.io Online first

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-46?page=com.atlassian.jira.plugin.s... ] Matt Mahoney updated SWSQE-46: ------------------------------ Team: Infrastructure (was: Infrastructure) Sprint: SWS QE Sprint 2 (was: SWS QE Sprint 2, Kiali QE Sprint 6) > Build SWS project CI pipeline on Openshif.io Online first > --------------------------------------------------------- > > Key: SWSQE-46 > URL: https://issues.jboss.org/browse/SWSQE-46 > Project: Kiali QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2276) MERGE3: a dead member as merge leader will never trigger a merge

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2276?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2276: -------------------------------- The root cause is actually not a merge issue, but the way we install a new view when the coordinator leaves: the *coordinator* creates the new view V (excluding itself), broadcasts it and waits for acks, or until a timeout ({{view_ack_collection_timeout}}) occurs. If a member (say member 7) drops the message, then STABLE has no chance of retransmitting V, as all members (including 7) will remove the coordinator (member 2) from their retransmission tables, and V is therefore not retransmitted. {{ASYM_ENCRYPT}} just happens to drop the message, as it doesn't have the new secret key yet, so it's causing the above problem through the message drop. We should therefore neither fix {{ASYM_ENCRYPT}} nor {{MERGE3}}, but the way a coordinator leaves gracefully. On second thought, we should probably also add code to {{MERGE3}} to handle the above scenario, as a second line of defense... > MERGE3: a dead member as merge leader will never trigger a merge > ---------------------------------------------------------------- > > Key: JGRP-2276 > URL: https://issues.jboss.org/browse/JGRP-2276 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.12 > > > When we have member(s) which have a view with a dead member as coordinator, when the dead member becomes part of the subgroup coordinators and _happens to be chosen as merge leader_, then a merge will never ensue. > Example: > * Member 2 (with view 2|5) was the previous coordinator and left the cluster, installing view 3|6 before stopping > ** View 2|5=\{2,3,4,5,6,7\}; view 3|6=\{3,4,5,6,7\} > * Member 7 didn't get view 3|6 and still has view 2|5 > * Everybody else has view 3|6 > * MERGE3 gets the following views: > ** 2|5: 7 // member 7 has this view > ** 3|6: 3,4,5,6 // members 3,4,5 and 6 have this view > * 2 and 3 are added to a _sorted set_ and the first member of the set (2) is chose as merge leader. 3 doesn't take any action, as it notices it won't be the merge leader > ** The reason 2 was first in the sorted set is that (possibly by coincidence) its UUID is *lower* than that of 3. If this wasn't the case, 3 would be merge leader and start (and successfully complete) a merge. However, with dead member 2 being picked as merge leader, a merge will never be triggered! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-240) Mesh Deployer Job - Add Option To NOT Deploy Envoy

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-240?page=com.atlassian.jira.plugin.... ] Matt Mahoney resolved SWSQE-240. -------------------------------- Resolution: Done > Mesh Deployer Job - Add Option To NOT Deploy Envoy > -------------------------------------------------- > > Key: SWSQE-240 > URL: https://issues.jboss.org/browse/SWSQE-240 > Project: Kiali QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > Priority: Minor > > Test mesh with pods that do not have Envloy side-car deployed is a valid configuration. Thus, adding the ability to the Jenkins Test-Mesh deplorer job will allow the automation of deploying such configurations. > _Its possible to have multiple pods behind a service and not all of those pods have an envoy side car installed. We should be able to detect this situation and alert the user to this error._ -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10539) ServletContainerInitializer instances aren't invoked in the specified order (WarMetaData order)

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-10539?page=com.atlassian.jira.plugin... ] Kabir Khan resolved WFLY-10539. ------------------------------- Fix Version/s: 14.0.0.CR1 Resolution: Done > ServletContainerInitializer instances aren't invoked in the specified order (WarMetaData order) > ----------------------------------------------------------------------------------------------- > > Key: WFLY-10539 > URL: https://issues.jboss.org/browse/WFLY-10539 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final, 12.0.0.Final, 13.0.0.Final > Reporter: Paulo Silva > Assignee: Stuart Douglas > Fix For: 14.0.0.CR1 > > > After several tests I've found that ServletContainerInitializer instances aren't being called in a deterministic order, even when an absolute-ordering is configured in web.xml. I've tested this in wildfly 10, 12 and 13. > Stepping through the code, on wildfly startup, I've found that ServletContainerInitializer instances are being collected to ScisMetaData.The problem is that they are being stored in a HashSet, and that makes no guarantees as to the iteration order! > The set is being initialized here: > {code:java} > Set<ServletContainerInitializer> scis = scisMetaData.getScis(); > Set<Class<? extends ServletContainerInitializer>> sciClasses = new HashSet<>(); > if (scis == null) { > scis = new HashSet<ServletContainerInitializer>(); > scisMetaData.setScis(scis); > } > {code} > And the ServletContainerInitializer implementations that are found in jars are being added here: > {code:java} > // Find local ServletContainerInitializer services > List<String> order = warMetaData.getOrder(); > Map<String, VirtualFile> localScis = warMetaData.getScis(); > if (order != null && localScis != null) { > for (String jar : order) { > VirtualFile sci = localScis.get(jar); > if (sci != null) { > scis.addAll(loadSci(classLoader, sci, jar, true, sciClasses)); > } > } > } > {code} > and later iterated and added to the DeployementInfo here (they are added to a List!): > {code:java} > if (scisMetaData != null && scisMetaData.getHandlesTypes() != null) { > for (final ServletContainerInitializer sci : scisMetaData.getScis()) { > final ImmediateInstanceFactory<ServletContainerInitializer> instanceFactory = new ImmediateInstanceFactory<>(sci); > d.addServletContainerInitalizer(new ServletContainerInitializerInfo(sci.getClass(), instanceFactory, scisMetaData.getHandlesTypes().get(sci))); > } > } > {code} > +But+, since scisMetaData.getScis() returns a HashSet, there is absolutely no guarantee that the iteration order is the same as the insertion order (the order that is imposed by warMetaData.getOrder()). > So a simple fix is to use a LinkedHashSet instead of a HashSet: > The ServletContainerInitializer instances are later iterated and called by insertion order (List iteration) in DeployementManagerImpl: > {code:java} > //then run the SCI's > for (final ServletContainerInitializerInfo sci : deploymentInfo.getServletContainerInitializers()) { > final InstanceHandle<? extends ServletContainerInitializer> instance = sci.getInstanceFactory().createInstance(); > try { > instance.getInstance().onStartup(sci.getHandlesTypes(), servletContext); > } finally { > instance.release(); > } > } > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-288) Kiali - Istio Checker to 0.8.0

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-288?page=com.atlassian.jira.plugin.... ] Matt Mahoney reassigned SWSQE-288: ---------------------------------- Assignee: Matt Mahoney (was: Sunil kondkar) > Kiali - Istio Checker to 0.8.0 > ------------------------------ > > Key: SWSQE-288 > URL: https://issues.jboss.org/browse/SWSQE-288 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Matt Mahoney > > We have a job http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Kiali-Istio-Checker > which checks Istio installation on OC. It works with 0.7.1 Istio. > Main jenkins pipeline is switched to Istio 0.8.0 already. > TODO > Update this job and the script to support Istio 0.8.0 version pods which are: > grafana-cd99bf478-2k9zj 1/1 Running 0 19m > istio-citadel-ff5696f6f-6m8rv 1/1 Running 0 19m > istio-cleanup-old-ca-qmd7k 0/1 Completed 0 19m > istio-egressgateway-58d98d898c-4qhx9 0/1 CrashLoopBackOff 7 19m > istio-ingressgateway-6bc7c7c4bc-867sz 0/1 CrashLoopBackOff 7 19m > istio-mixer-post-install-kjhhk 0/1 Completed 0 19m > istio-pilot-6c5c6b586c-gq6gt 2/2 Running 0 19m > istio-policy-5c7fbb4b9f-j2jjd 2/2 Running 0 19m > istio-sidecar-injector-dbd67c88d-ffkgm 1/1 Running 0 19m > istio-statsd-prom-bridge-6dbb7dcc7f-fcl8f 1/1 Running 0 19m > istio-telemetry-54b5bf4847-5wq78 2/2 Running 0 19m > istio-tracing-67dbb5b89f-l52vk 1/1 Running 0 19m > prometheus-586d95b8d9-dw9xl 1/1 Running 0 19m > servicegraph-6d86dfc6cb-25qtp 1/1 Running 1 19m -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-992) org.jboss.security.Base64Encoder doesn't work for certain lengths (1026 or 3072 for example)

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/SECURITY-992?page=com.atlassian.jira.plug... ] Ilia Vassilev updated SECURITY-992: ----------------------------------- Fix Version/s: PicketBox_5_1_1.Beta1 > org.jboss.security.Base64Encoder doesn't work for certain lengths (1026 or 3072 for example) > -------------------------------------------------------------------------------------------- > > Key: SECURITY-992 > URL: https://issues.jboss.org/browse/SECURITY-992 > Project: PicketBox > Issue Type: Bug > Components: JBossSX > Affects Versions: PicketBox_5_1_0.Final > Reporter: Ricardo Martin Camarero > Assignee: Ilia Vassilev > Fix For: PicketBox_5_1_1.Beta1 > > Attachments: Reproducer.java > > > When a byte array of certain lengths (1026 and 3072 for example) is encoded in base64 using the class {{org.jboss.security.Base64Encoder}} the last chunk of four bytes is omitted. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-992) org.jboss.security.Base64Encoder doesn't work for certain lengths (1026 or 3072 for example)

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/SECURITY-992?page=com.atlassian.jira.plug... ] Ilia Vassilev updated SECURITY-992: ----------------------------------- Git Pull Request: https://github.com/picketbox/picketbox/pull/79 > org.jboss.security.Base64Encoder doesn't work for certain lengths (1026 or 3072 for example) > -------------------------------------------------------------------------------------------- > > Key: SECURITY-992 > URL: https://issues.jboss.org/browse/SECURITY-992 > Project: PicketBox > Issue Type: Bug > Components: JBossSX > Affects Versions: PicketBox_5_1_0.Final > Reporter: Ricardo Martin Camarero > Assignee: Ilia Vassilev > Attachments: Reproducer.java > > > When a byte array of certain lengths (1026 and 3072 for example) is encoded in base64 using the class {{org.jboss.security.Base64Encoder}} the last chunk of four bytes is omitted. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 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 2018