June 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10532) Disable frequently failing test in clustering.web

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10532?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-10532: ---------------------------------- Attachment: Pull_Request_Linux_15524.log > Disable frequently failing test in clustering.web > ------------------------------------------------- > > Key: WFLY-10532 > URL: https://issues.jboss.org/browse/WFLY-10532 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 13.0.0.Final > Reporter: Jeff Mesnil > Assignee: Paul Ferraro > Attachments: Pull_Request_Linux_15524.log, server.log1.txt, server.log2.txt, server.log3.txt > > > Tests that fails frequently: > * ConcurrentFineWebFailoverTestCase - https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=... > * ReplicationForNegotiationAuthenticatorTestCase - https://ci.wildfly.org/project.html?projectId=WF_PullRequest&testNameId=-... > * CoarseWebFailoverTestCase - https://ci.wildfly.org/project.html?projectId=WF_PullRequest&testNameId=6... > This issue is distinct from WFLY-10026 as failures also occurs on Linux. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10532) Disable frequently failing test in clustering.web

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10532?page=com.atlassian.jira.plugin... ] Radoslav Husar commented on WFLY-10532: --------------------------------------- Attached logs from one run so that we have at least some context once the jobs get deleted. > Disable frequently failing test in clustering.web > ------------------------------------------------- > > Key: WFLY-10532 > URL: https://issues.jboss.org/browse/WFLY-10532 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 13.0.0.Final > Reporter: Jeff Mesnil > Assignee: Paul Ferraro > Attachments: Pull_Request_Linux_15524.log, server.log1.txt, server.log2.txt, server.log3.txt > > > Tests that fails frequently: > * ConcurrentFineWebFailoverTestCase - https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=... > * ReplicationForNegotiationAuthenticatorTestCase - https://ci.wildfly.org/project.html?projectId=WF_PullRequest&testNameId=-... > * CoarseWebFailoverTestCase - https://ci.wildfly.org/project.html?projectId=WF_PullRequest&testNameId=6... > This issue is distinct from WFLY-10026 as failures also occurs on Linux. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10532) Disable frequently failing test in clustering.web

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10532?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-10532: ---------------------------------- Attachment: server.log1.txt server.log2.txt server.log3.txt > Disable frequently failing test in clustering.web > ------------------------------------------------- > > Key: WFLY-10532 > URL: https://issues.jboss.org/browse/WFLY-10532 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 13.0.0.Final > Reporter: Jeff Mesnil > Assignee: Paul Ferraro > Attachments: server.log1.txt, server.log2.txt, server.log3.txt > > > Tests that fails frequently: > * ConcurrentFineWebFailoverTestCase - https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=... > * ReplicationForNegotiationAuthenticatorTestCase - https://ci.wildfly.org/project.html?projectId=WF_PullRequest&testNameId=-... > * CoarseWebFailoverTestCase - https://ci.wildfly.org/project.html?projectId=WF_PullRequest&testNameId=6... > This issue is distinct from WFLY-10026 as failures also occurs on Linux. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10540) jboss-ejb-client.xml is unable to specify global cluster config

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-10540: ----------------------------------- Summary: jboss-ejb-client.xml is unable to specify global cluster config Key: WFLY-10540 URL: https://issues.jboss.org/browse/WFLY-10540 Project: WildFly Issue Type: Enhancement Components: EJB Affects Versions: 13.0.0.Final Reporter: Brad Maxwell When configuring an Wildfly instance with EJB Client applications to make remote EJB calls to another Wildfly instance with clustering enabled using a server to server connection configuration, the client Wildfly will specify remote-outbound-connection in the remoting subsystem. The client Wildfly instance will create and maintain these 2 connections in this example below. Client applications deployed on the client Wildfly instance will then package a jboss-ejb-client.xml in the application which specifies the remote server aliases that it wants to have access to. For the application to use clustered ejb, it then specifies the cluster information in the jboss-ejb-client.xml, where it has to specify connection information like username, connection options as opposed to just an alias as in the case of remoting-ejb-receiver. The cluster info should be configured in the JBoss profile xml so that client apps jboss-ejb-client.xml can just reference aliases like the non clustered connections to avoid applications creating their own connections to the same cluster nodes. {code} <subsystem xmlns="urn:jboss:domain:remoting:3.0"> <endpoint/> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> <outbound-connections> <remote-outbound-connection name="remote-ejb-connection-1" outbound-socket-binding-ref="remote-ejb-1" username="ejbuser" security-realm="ApplicationRealm" protocol="http-remoting"> <properties> <property name="SASL_POLICY_NOANONYMOUS" value="false"/> <property name="SASL_DISALLOWED_MECHANISMS" value="JBOSS-LOCAL-USER"/> <property name="SSL_ENABLED" value="false"/> </properties> </remote-outbound-connection> <remote-outbound-connection name="remote-ejb-connection-2" outbound-socket-binding-ref="remote-ejb-2" username="ejbuser" security-realm="ApplicationRealm" protocol="http-remoting"> <properties> <property name="SASL_POLICY_NOANONYMOUS" value="false"/> <property name="SASL_DISALLOWED_MECHANISMS" value="JBOSS-LOCAL-USER"/> <property name="SSL_ENABLED" value="false"/> </properties> </remote-outbound-connection> </outbound-connections> </subsystem> {code} {code} <jboss-ejb-client xmlns:xsi="urn:jboss:ejb-client:1.2" xsi:noNamespaceSchemaLocation="jboss-ejb-client_1_2.xsd"> <client-context> <ejb-receivers exclude-local-receiver="true"> <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-1" /> <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-2" /> </ejb-receivers> <clusters> <cluster name="ejb" security-realm="ApplicationRealm" username="ejb-cluster-username"> <connection-creation-options> <property name="org.xnio.Options.SSL_ENABLED" value="false" /> <property name="org.xnio.Options.SASL_POLICY_NOANONYMOUS" value="false" /> </connection-creation-options> </cluster> </clusters> </client-context> </jboss-ejb-client> {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10532) Disable frequently failing test in clustering.web

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10532?page=com.atlassian.jira.plugin... ] Radoslav Husar reopened WFLY-10532: ----------------------------------- This shouldn't have been resolved -- the point of the issue is to fix those intermittent failures. > Disable frequently failing test in clustering.web > ------------------------------------------------- > > Key: WFLY-10532 > URL: https://issues.jboss.org/browse/WFLY-10532 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 13.0.0.Final > Reporter: Jeff Mesnil > Assignee: Paul Ferraro > > Tests that fails frequently: > * ConcurrentFineWebFailoverTestCase - https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=... > * ReplicationForNegotiationAuthenticatorTestCase - https://ci.wildfly.org/project.html?projectId=WF_PullRequest&testNameId=-... > * CoarseWebFailoverTestCase - https://ci.wildfly.org/project.html?projectId=WF_PullRequest&testNameId=6... > This issue is distinct from WFLY-10026 as failures also occurs on Linux. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10532) Disable frequently failing test in clustering.web

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10532?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-10532: ---------------------------------- Fix Version/s: (was: 14.0.0.CR1) > Disable frequently failing test in clustering.web > ------------------------------------------------- > > Key: WFLY-10532 > URL: https://issues.jboss.org/browse/WFLY-10532 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 13.0.0.Final > Reporter: Jeff Mesnil > Assignee: Paul Ferraro > > Tests that fails frequently: > * ConcurrentFineWebFailoverTestCase - https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=... > * ReplicationForNegotiationAuthenticatorTestCase - https://ci.wildfly.org/project.html?projectId=WF_PullRequest&testNameId=-... > * CoarseWebFailoverTestCase - https://ci.wildfly.org/project.html?projectId=WF_PullRequest&testNameId=6... > This issue is distinct from WFLY-10026 as failures also occurs on Linux. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9364) Closing an EJBClientContext sometimes hangs causing high CPU usage

by crina boitor (JIRA)

[ https://issues.jboss.org/browse/WFLY-9364?page=com.atlassian.jira.plugin.... ] crina boitor commented on WFLY-9364: ------------------------------------ Thank you. We'll try with XNIO 3.5.4 and if it still reproduces we'll upgrade to Wildfly 11 or higher. > Closing an EJBClientContext sometimes hangs causing high CPU usage > ------------------------------------------------------------------ > > Key: WFLY-9364 > URL: https://issues.jboss.org/browse/WFLY-9364 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final > Environment: Server: > - OS: > Red Hat Enterprise Linux Server release 7.2 (Maipo) > - JDK: > java version "1.8.0_144" > Java(TM) SE Runtime Environment (build 1.8.0_144-b01) > Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode) > - WildFly: > WildFly 10.1.0.Final > Client: > - OS: > Red Hat Enterprise Linux Server release 7.2 (Maipo) > - JDK: > java version "1.8.0_144" > Java(TM) SE Runtime Environment (build 1.8.0_144-b01) > Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode) > Reporter: Marius Tantareanu > Assignee: Jason Greene > Fix For: 11.0.0.Final > > Attachments: echo-client.zip, output_rhel7.txt, output_win10.txt, simple-ear.ear, td_rhel7.txt, td_win10.txt > > > EJBClientContext.close() sometimes hangs and causes high CPU usage. We have a WildFly client that uses EJB client API to invoke some EJBs remotely. > Basically the client executes the following actions in a loop: > - setup an EJBClientContext programatically > - create a JNDI context > - lookup an EJB and invoke some operations on it > - close the JNDI context and the EJBClientContext > After the client runs a few hundreds iterations (the actual number of iterations varies quite a lot from one run to another) it blocks while invoking EJBClientContext.close(). Also one XNIO thread in the client app is constantly consuming one CPU core (full thread dump from the client app is attached). I was only able to reproduce this when connecting over TLS (port 8443). When using the unsecure port (8080) the problem does not reproduce (or it reproduces much less frequently and I didn't run enough iterations to catch it). > Once the client app enters this state, top shows something like (notice the CPU usage of thread 12512): > >top -H -p 6463 > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 12512 root 20 0 11.527g 222680 13788 R 99.3 0.7 141:10.99 java > 6466 root 20 0 11.527g 222680 13788 S 0.3 0.7 0:07.05 java > 6467 root 20 0 11.527g 222680 13788 S 0.3 0.7 0:06.97 java > 6477 root 20 0 11.527g 222680 13788 S 0.3 0.7 0:04.24 java > 6463 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java > 6464 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:03.46 java > 6465 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:06.94 java > 6468 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:07.02 java > 6469 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:16.42 java > 6470 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.01 java > 6471 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.01 java > 6472 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java > 6473 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:06.87 java > 6474 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:06.70 java > 6475 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:03.09 java > 6476 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java > 12513 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java > 12514 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java > 12515 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java > 12516 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java > 12517 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java > 12518 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java > 12519 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java > 12520 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java > 12523 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java > 12524 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java > 12597 root 20 0 11.527g 222680 13788 S 0.0 0.7 0:00.00 java > The thread that causes the CPU usage is the following: > "Remoting "config-based-ejb-client-endpoint" I/O-1" #6025 daemon prio=5 os_prio=0 tid=0x00007f2f709d3000 nid=0x30e0 runnable [0x00007f2e7f9be000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) > - locked <0x00000005cc1844e8> (a sun.nio.ch.Util$3) > - locked <0x00000005cc19f258> (a java.util.Collections$UnmodifiableSet) > - locked <0x00000005cc184468> (a sun.nio.ch.EPollSelectorImpl) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:515) > The client app main thread is blocked as below: > "main" #1 prio=5 os_prio=0 tid=0x00007f2f70008800 nid=0x1940 in Object.wait() [0x00007f2f76350000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:502) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:190) > - locked <0x00000005cc18de48> (a java.lang.Object) > at org.jboss.ejb.client.remoting.ConnectionPool.safeClose(ConnectionPool.java:177) > at org.jboss.ejb.client.remoting.ConnectionPool.release(ConnectionPool.java:104) > - locked <0x00000005cbd369e0> (a org.jboss.ejb.client.remoting.ConnectionPool) > at org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection.close(ConnectionPool.java:198) > at org.jboss.ejb.client.remoting.RemotingConnectionManager.safeClose(RemotingConnectionManager.java:65) > - locked <0x00000005cc1a6840> (a java.util.Collections$SynchronizedRandomAccessList) > at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector$ContextCloseListener.contextClosed(ConfigBasedEJBClientContextSelector.java:220) > at org.jboss.ejb.client.EJBClientContext.close(EJBClientContext.java:1305) > - locked <0x00000005cc1a6888> (a org.jboss.ejb.client.EJBClientContext) > at com.microfocus.echoclient.EchoClient.disconnect(EchoClient.java:66) > at com.microfocus.echoclient.EchoClient.connectDisconnect(EchoClient.java:54) > at com.microfocus.echoclient.EchoClient.main(EchoClient.java:36) > The problem also reproduces on Windows (full thread dump of the client app is attached). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-618) Dead code in DEREncoder

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-618?page=com.atlassian.jira.plugin.sy... ] Ilia Vassilev commented on ELY-618: ----------------------------------- [~fjuma] Correct me if I'm wrong, but the whole logic in DEREncoder is designed for tag numbers <= 30 (single octet). According to the spec [1], tag numbers > 30 needs multiple octets and the implementation in {{DEREncoder.writeTag()}} method is intended to do this. Unfortunately, the logic only works on single octet tags (tag number <= 30). The good think is that all of the tags in {{ASN1.java}} are single octet and work fine with the current implementation. The public methods {{startExplicit(int number), startExplicit(int clazz, int number), encodeImplicit(int number), encodeImplicit(int clazz, int number)}} take tag number but the implementation will only work on tags <= 30. If we decide to keep the current implementation (tag number <= 30), we can remove some of the logic in {{DEREncoder.writeTag()}} method and add checks in the public methods. To implement the full spec, some redesign is needed. [1] https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf (page 4) > Dead code in DEREncoder > ----------------------- > > Key: ELY-618 > URL: https://issues.jboss.org/browse/ELY-618 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > Labels: static_analysis > > There is an unintentional dead code in writeTag method of org.wildfly.security.asn1.DEREncoder. Variable {{tagNumber}} can be assigned to 31 as its maximal value from {{int tagNumber = tag & TAG_NUMBER_MASK;}} (because {{TAG_NUMBER_MASK = 0x1f}}) on line 576 [1] which means that condition {{if (tagNumber < 128)}} on line 582 is always true. It causes that else branch is never executed. > [1] https://github.com/wildfly-security/wildfly-elytron/blob/4453ea40a7a617b6... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-206) Investegate b21 Docker Failures

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-206?page=com.atlassian.jira.plugin.... ] Filip Brychta resolved SWSQE-206. --------------------------------- Resolution: Done No more exceptions after the upgrade -> closing > Investegate b21 Docker Failures > ------------------------------- > > Key: SWSQE-206 > URL: https://issues.jboss.org/browse/SWSQE-206 > Project: Kiali QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Filip Brychta > Priority: Minor > > Docker periodical needs to be restarted, which is causing pod failures. This issue appears to have started when clusters were upgraded to OS3.9. > Investigate reason for failures. Resolve if at all possible. > Temp work-around: > 1) Restart docker service > 2) Reboot instance if #1 failed -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-286) Update RHEL on infrastructure hosts

by Filip Brychta (JIRA)

Filip Brychta created SWSQE-286: ----------------------------------- Summary: Update RHEL on infrastructure hosts Key: SWSQE-286 URL: https://issues.jboss.org/browse/SWSQE-286 Project: Kiali QE Issue Type: Task Reporter: Filip Brychta Assignee: Filip Brychta We need to update RHEL on following hosts: * b01.jonqe.lab.eng.bos.redhat.com * jenkins2.bc.jonqe.lab.eng.bos.redhat.com * netser.jonqe.lab.eng.bos.redhat.com * foreman.jonqe.lab.eng.bos.redhat.com * backup.bc.jonqe.lab.eng.bos.redhat.com * web.bc.jonqe.lab.eng.bos.redhat.com * rhevm.jonqe.lab.eng.bos.redhat.com -- 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