April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2266) RouterStubManager.run() endless reconnect loop burning a CPU

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2266?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2266: --------------------------- Fix Version/s: 4.0.12 > RouterStubManager.run() endless reconnect loop burning a CPU > ------------------------------------------------------------ > > Key: JGRP-2266 > URL: https://issues.jboss.org/browse/JGRP-2266 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.11 > Environment: Small cluster (~ 20 nodes), some nodes are connected through OpenVPN tunnels. MacOS and Linux nodes. > Reporter: Emmeran Seehuber > Assignee: Bela Ban > Fix For: 4.0.12 > > Attachments: cs_stack.xml > > > RouterStubManager.run() tries in a loop to reconnect all stubs currently not connected. When for whatever reason it is not possible to connect one of this stubs, the method spins in a endless loop and burns a CPU. > E.g. sometimes the VPN tunnel is down or one of the TCPGOSSIP hosts is down. > No idea if it is really required to loop here, but at least it should do some some Thread.yield() or or sleep() here. As this run() method is called periodically it should not be required to do a endless loop here, should it? Maybe only loop e.g. three times and then give up? > As the all nodes in the cluster are iMac workstations or special render Linux slaves, burning a CPU is very annoying. The CPU should rather be spend on the Blender render jobs or for the interactive work the people are doing on their iMacs. (JGroups is used here to distribute render jobs within the cluster) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2266) RouterStubManager.run() endless reconnect loop burning a CPU

by Emmeran Seehuber (JIRA)

Emmeran Seehuber created JGRP-2266: -------------------------------------- Summary: RouterStubManager.run() endless reconnect loop burning a CPU Key: JGRP-2266 URL: https://issues.jboss.org/browse/JGRP-2266 Project: JGroups Issue Type: Bug Affects Versions: 4.0.11 Environment: Small cluster (~ 20 nodes), some nodes are connected through OpenVPN tunnels. MacOS and Linux nodes. Reporter: Emmeran Seehuber Assignee: Bela Ban Attachments: cs_stack.xml RouterStubManager.run() tries in a loop to reconnect all stubs currently not connected. When for whatever reason it is not possible to connect one of this stubs, the method spins in a endless loop and burns a CPU. E.g. sometimes the VPN tunnel is down or one of the TCPGOSSIP hosts is down. No idea if it is really required to loop here, but at least it should do some some Thread.yield() or or sleep() here. As this run() method is called periodically it should not be required to do a endless loop here, should it? Maybe only loop e.g. three times and then give up? As the all nodes in the cluster are iMac workstations or special render Linux slaves, burning a CPU is very annoying. The CPU should rather be spend on the Blender render jobs or for the interactive work the people are doing on their iMacs. (JGroups is used here to distribute render jobs within the cluster) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3577) Add support for coloured output to CLI

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3577?page=com.atlassian.jira.plugi... ] Ingo Weiss updated WFCORE-3577: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3232 (was: https://github.com/iweiss/wildfly-core/tree/WFCORE-3577) > Add support for coloured output to CLI > -------------------------------------- > > Key: WFCORE-3577 > URL: https://issues.jboss.org/browse/WFCORE-3577 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Affects Versions: 4.0.0.Alpha10 > Reporter: Ingo Weiss > Assignee: Jean-Francois Denise > > Add support to colour for CLI outputs -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10258) Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin... ] Lin Gao updated WFLY-10258: --------------------------- Labels: downstream_dependency (was: ) > Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew > --------------------------------------------------------------------------------------------- > > Key: WFLY-10258 > URL: https://issues.jboss.org/browse/WFLY-10258 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Affects Versions: 12.0.0.Final > Reporter: Jörg Bäsner > Labels: downstream_dependency > > Scenario: > - server-1 (intermediary) > -- Running standalone profile > -- Has a remote-outbound-connection pointing at server-2 through server-2's public IP address > -- Intermediary bean need to lookup the Target bean in server-2 and also inject the {{TransactionManager}} > -- Intermediary bean need to enlist a _dummy_ XAResource > - server-2 (target) > -- disable {{JBOSS-LOCAL-USER}} auth > -- Target bean needs to be annotated with {{@REQUIRES_NEW}} (important) > - Standalone EJB client invokes an intermediary bean server-1, which as a result invokes target bean on server-2. > The _dummy_ XAResource should log in the {{commit}} method whether one-phase optimization is being used like: > {code} > @Override > public void commit(Xid arg0, boolean onePhaseOptim) throws XAException { > logger.info("-- Committing in the client resource. One-phase optimisation is: " + onePhaseOptim + " --" > + (onePhaseOptim ? "" : " -> TWO-PHASE COMMIT !!!")); > } > {code} > In this scenario it is expected that the one-phase optimization is being used! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2506) Lexical scope for FEEL Function invocation

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-2506: -------------------------------------- Summary: Lexical scope for FEEL Function invocation Key: DROOLS-2506 URL: https://issues.jboss.org/browse/DROOLS-2506 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari A script like {code:java} { myimport : { f1 : function() \"Hi\", x1 : function(name) f1() + \" \" + name }, r1 : myimport.x1(\"John\") }.r {code} shoudl evaluate to "Hi John" but the invocation of "myimport.x1" is not being evaluated with the correct lexical scope -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2257) UDP#PacketReceiver stuck in busy loop when socket throws closed exception but socket is not closed

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2257?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2257: -------------------------------- So you're saying that the socket read throws a SocketClosedException, but Socket.isClosed() returns false? Hmm, is this a bug in the JVM? I don't see how I could fix this... > UDP#PacketReceiver stuck in busy loop when socket throws closed exception but socket is not closed > -------------------------------------------------------------------------------------------------- > > Key: JGRP-2257 > URL: https://issues.jboss.org/browse/JGRP-2257 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.12 > Environment: Windows Server 2016, 32GBytes memory running as a Hyper-V guest > java version "1.8.0_131" > Java(TM) SE Runtime Environment (build 1.8.0_131-b11) > Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode) > It was reported with just a single node running. > Reporter: Paul Illingworth > Assignee: Bela Ban > Fix For: 4.0.12 > > > I have a had a report of a scenario where it looks like the UDP#PacketReceiver is stuck spinning in a busy loop. The following is a snippet of the log file from the system in question. > {noformat} > 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet > java.net.SocketException: socket closed > at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method) > at java.net.DatagramSocket.receive(DatagramSocket.java:743) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694) > at java.lang.Thread.run(Thread.java:748) > > 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet > java.net.SocketException: socket closed > at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method) > at java.net.DatagramSocket.receive(DatagramSocket.java:743) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694) > at java.lang.Thread.run(Thread.java:748) > > 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet > java.net.SocketException: socket closed > at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method) > at java.net.DatagramSocket.receive(DatagramSocket.java:743) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694) > at java.lang.Thread.run(Thread.java:748) > {noformat} > Looking at the code it looks like the call to receive a packet > {code:java} > receiver_socket.receive(packet); > {code} > results in an exception being thrown because the socket is closed but then when the exception is caught > {code:java} > if(receiver_socket.isClosed()) { > {code} > method is queried which says the socket has not been closed and the loop then continues for ever. > I guess this is related to JGRP-1669. To quote > _I hope there is no condition which causes the socket receive() to spit out endless exceptions while not being closed..._ -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9731) The fix for WFLY-4625 breaks PolicyContext("javax.security.auth.subject.container") in CXF web service with STS

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-9731?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-9731: ----------------------------------------------- Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1352418|https://bugzilla.redhat.com/show_bug.cgi?id=1352418] from ON_QA to VERIFIED > The fix for WFLY-4625 breaks PolicyContext("javax.security.auth.subject.container") in CXF web service with STS > --------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9731 > URL: https://issues.jboss.org/browse/WFLY-9731 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Petr Jurak > Assignee: Petr Jurak > > Web service with STS (Picketlink) returns wrong subject with PolicyContext("javax.security.auth.subject.container"). > It seems that configured login modules are not called since SecurityContext was created by SAML2Handler for the same security domain and are skipped because of WFLY-4625. > Reproducer is attached in BZ-1352418. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2255) Message Bundling in TUNNEL mode

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2255?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2255. ---------------------------- Resolution: Done > Message Bundling in TUNNEL mode > ------------------------------- > > Key: JGRP-2255 > URL: https://issues.jboss.org/browse/JGRP-2255 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.6.4 > Reporter: Bharad S > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.12 > > > Hi, I'm using JGroups v3.6.4 and it is working great. I have a quick question -- > TUNNEL.java's 'send' method clearly says -- "// we don't currently support message bundling in TUNNEL" > If I wish to use 'SenderSendsWithTimerBundler' (i.e., bundle and send when queued messages are 64K or 20ms have passed), could you please let me know what options I have? E.g., whether I need to use a later version that supports bundling with TUNNEL or is there some other option. Thanks! > Regards, > -Bharad -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-90) Remove b24 and b25 from hawkular performace cluster

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-90?page=com.atlassian.jira.plugin.s... ] Filip Brychta resolved SWSQE-90. -------------------------------- Resolution: Done All jenkins jobs using this are disabled. RHEL 7.5 is installed there. There is ~500 GB of unallocated space which should be used for docker pool. Note that b24 and b25 are still connected directly via cable using em4 > Remove b24 and b25 from hawkular performace cluster > --------------------------------------------------- > > Key: SWSQE-90 > URL: https://issues.jboss.org/browse/SWSQE-90 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Minor > > Those 2 blades are used for hawkular performance testing. We agreed to drop that testing so those can be cleaned. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10308) PolicyContext.getContext("javax.security.auth.Subject.container")

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-10308?page=com.atlassian.jira.plugin... ] Lin Gao moved JBEAP-14690 to WFLY-10308: ---------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-10308 (was: JBEAP-14690) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: (was: 7.1.0.GA) Fix Version/s: (was: 7.1.3.GA) > PolicyContext.getContext("javax.security.auth.Subject.container") > ----------------------------------------------------------------- > > Key: WFLY-10308 > URL: https://issues.jboss.org/browse/WFLY-10308 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Lin Gao > Assignee: Darran Lofthouse > > PolicyContext.getContext("javax.security.auth.Subject.container") returns null when using elytron to protect a web application. > This should return the authenticated subject. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 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 April 2018