January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated JGRP-1905: ------------------------------- Priority: Critical (was: Major) > FORK: RPCs might block if fork channel or fork stack is not available > --------------------------------------------------------------------- > > Key: JGRP-1905 > URL: https://issues.jboss.org/browse/JGRP-1905 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 3.6.2 > > > When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out. > h5. Solution > * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available"). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on JGRP-1905: ------------------------------------ Hey Bela, I need to boost the priority of this... Infinispan 7.0.3 made a change that results in an RPC on view change. https://github.com/infinispan/infinispan/commit/37058d94fe8b52fc6aacd6aa9... Here's what I'm seeing: # Node 1 starts. # Node 1 creates and connects channel "ee". # Node 1 creates fork channel "web". # Node 1 starts Infinispan's transport and connects fork channel "web" and starts its cache. # Node 2 starts. # Node 2 creates and connects its "ee" channel. # The Infinispan transport on node 1 detects the view change and sends an RPC using its "web" fork channel # The RPC is received by Node 2, but the "web" fork does not yet exist triggering an NPE in ForkProtocolStack.up(Event): https://github.com/belaban/JGroups/blob/master/src/org/jgroups/fork/ForkP... ... since, in this case, get(hdr.getForkChannelId()) returns null. # Node 2 creates fork channel "web". # Node 2 starts Infinispan's transport and connects fork channel "web" and starts its cache. # The RPC initiated on Node 1 times out waiting for responses. > FORK: RPCs might block if fork channel or fork stack is not available > --------------------------------------------------------------------- > > Key: JGRP-1905 > URL: https://issues.jboss.org/browse/JGRP-1905 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 3.6.2 > > > When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out. > h5. Solution > * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available"). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ] Paul Ferraro edited comment on JGRP-1905 at 1/9/15 10:01 AM: ------------------------------------------------------------- Hey Bela, I need to boost the priority of this... Infinispan 7.0.3 made a change that results in an immediate RPC on view change. https://github.com/infinispan/infinispan/commit/37058d94fe8b52fc6aacd6aa9... Here's what I'm seeing: # Node 1 starts. # Node 1 creates and connects channel "ee". # Node 1 creates fork channel "web". # Node 1 starts Infinispan's transport and connects fork channel "web" and starts its cache. # Node 2 starts. # Node 2 creates and connects its "ee" channel. # The Infinispan transport on node 1 detects the view change and sends an RPC using its "web" fork channel # The RPC is received by Node 2, but the "web" fork does not yet exist triggering an NPE in ForkProtocolStack.up(Event): https://github.com/belaban/JGroups/blob/master/src/org/jgroups/fork/ForkP... ... since, in this case, get(hdr.getForkChannelId()) returns null. # Node 2 creates fork channel "web". # Node 2 starts Infinispan's transport and connects fork channel "web" and starts its cache. # The RPC initiated on Node 1 times out waiting for responses. was (Author: pferraro): Hey Bela, I need to boost the priority of this... Infinispan 7.0.3 made a change that results in an RPC on view change. https://github.com/infinispan/infinispan/commit/37058d94fe8b52fc6aacd6aa9... Here's what I'm seeing: # Node 1 starts. # Node 1 creates and connects channel "ee". # Node 1 creates fork channel "web". # Node 1 starts Infinispan's transport and connects fork channel "web" and starts its cache. # Node 2 starts. # Node 2 creates and connects its "ee" channel. # The Infinispan transport on node 1 detects the view change and sends an RPC using its "web" fork channel # The RPC is received by Node 2, but the "web" fork does not yet exist triggering an NPE in ForkProtocolStack.up(Event): https://github.com/belaban/JGroups/blob/master/src/org/jgroups/fork/ForkP... ... since, in this case, get(hdr.getForkChannelId()) returns null. # Node 2 creates fork channel "web". # Node 2 starts Infinispan's transport and connects fork channel "web" and starts its cache. # The RPC initiated on Node 1 times out waiting for responses. > FORK: RPCs might block if fork channel or fork stack is not available > --------------------------------------------------------------------- > > Key: JGRP-1905 > URL: https://issues.jboss.org/browse/JGRP-1905 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 3.6.2 > > > When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out. > h5. Solution > * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available"). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2980) TLS client authentication configuration not working

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2980?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-2980: ----------------------------------- Guys, I cannot reproduce this. We also test this as part of our testsuite. see for the test itself: https://github.com/wildfly/wildfly/blob/master/testsuite/integration/manu... I would say problem is in certificates you use and how are they generated. > TLS client authentication configuration not working > --------------------------------------------------- > > Key: WFLY-2980 > URL: https://issues.jboss.org/browse/WFLY-2980 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Reporter: dfisher > Assignee: Tomaz Cerar > > Configuration of a security realm with a truststore does not result in an SSL trust manager with the appropriate certificate authorities. > This configuration: > {code} > <security-realm name="HTTPSRealm"> > <server-identities> > <ssl> > <keystore alias="server" path="/path/to/my.keystore" keystore-password="changeit" /> > </ssl> > </server-identities> > <authentication> > <truststore path="/path/to/my.truststore" keystore-password="changeit" /> > </authentication> > </security-realm> > {code} > Should expose the certificates in my.truststore as accepted authorities for client authentication. > An SSL debug shows that no authorities are configured: > {code} > *** CertificateRequest > Cert Types: RSA, DSS, ECDSA > Cert Authorities: > <Empty> > *** ServerHelloDone > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2980) TLS client authentication configuration not working

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2980?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-2980. ------------------------------- Resolution: Cannot Reproduce Bug > TLS client authentication configuration not working > --------------------------------------------------- > > Key: WFLY-2980 > URL: https://issues.jboss.org/browse/WFLY-2980 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Reporter: dfisher > Assignee: Tomaz Cerar > > Configuration of a security realm with a truststore does not result in an SSL trust manager with the appropriate certificate authorities. > This configuration: > {code} > <security-realm name="HTTPSRealm"> > <server-identities> > <ssl> > <keystore alias="server" path="/path/to/my.keystore" keystore-password="changeit" /> > </ssl> > </server-identities> > <authentication> > <truststore path="/path/to/my.truststore" keystore-password="changeit" /> > </authentication> > </security-realm> > {code} > Should expose the certificates in my.truststore as accepted authorities for client authentication. > An SSL debug shows that no authorities are configured: > {code} > *** CertificateRequest > Cert Types: RSA, DSS, ECDSA > Cert Authorities: > <Empty> > *** ServerHelloDone > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2893) Determine cause of unreported test failures

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2893?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-2893. ------------------------------- Resolution: Done This hasn't happened since, i did add few more safeguards just to make sure this doesn't happen again. > Determine cause of unreported test failures > ------------------------------------------- > > Key: WFLY-2893 > URL: https://issues.jboss.org/browse/WFLY-2893 > Project: WildFly > Issue Type: Task > Components: Build System, Test Suite > Affects Versions: 8.0.0.CR1 > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > > Identify the reason why the failing tests that needed https://github.com/wildfly/wildfly/commit/90643bc435a9ba439cf2988e5b7407d... to get working did not fail the build. Those tests were failing for 2.5 months. Fortunately it was just a test problem, not a broken feature. > They involved separate surefire executions. We want to avoid those, but sometimes they are needed to use different config files. We have separate executions in testsuite/integration/basic as well, covering a much broader scope, so if this kind of problem happened there as well we could have a big problem. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3364) There is no way to change "task-core-threads"

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3364?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-3364. ------------------------------- Resolution: Out of Date > There is no way to change "task-core-threads" > --------------------------------------------- > > Key: WFLY-3364 > URL: https://issues.jboss.org/browse/WFLY-3364 > Project: WildFly > Issue Type: Bug > Components: IO > Affects Versions: 8.1.0.CR1 > Environment: Ubuntu 14.04 > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > Reporter: Jay Xu > Assignee: Tomaz Cerar > > I tried to change the value of "task-core-threads" in web admin console to 128, but after restart it is set back to the default value 2. I searched in standalone.xml and didn't found any "128" in it. > Then I guessed and tried to add an attribute "task-core-threads" in the work config xml but that made wildfly fail to start with an error like "worker node doesn't have attribute task-core-threads": > {code:xml} > <worker name="default" io-threads="8" task-max-threads="512" task-core-threads="128"/> > {code} > So, "task-core-threads" is just a fake? My app server now meets a performance bottleneck for http connections, how to change task-core-threads's value? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-113) Move UsernamePasswordHashUtil main method functions to Main

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-113?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-113. ---------------------------------- Fix Version/s: 1.0.0.Alpha1 (was: 1.0.0.Beta1) Resolution: Done > Move UsernamePasswordHashUtil main method functions to Main > ----------------------------------------------------------- > > Key: ELY-113 > URL: https://issues.jboss.org/browse/ELY-113 > Project: WildFly Elytron > Issue Type: Sub-task > Components: Utils > Reporter: David Lloyd > Assignee: Jan Kalina > Priority: Minor > Fix For: 1.0.0.Alpha1 > > > The UsernamePasswordHashUtil main routine should be part of the single command-line entry point class, Main. Or, possibly even eliminated in favor of general password codec/generation routines. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-67) method-params containing an array not correctly processed for EJB2.1 with CMT

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-67?page=com.atlassian.jira.plugin.sy... ] RH Bugzilla Integration updated WFLY-67: ---------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1180565, https://bugzilla.redhat.com/show_bug.cgi?id=1180571 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1180565) > method-params containing an array not correctly processed for EJB2.1 with CMT > ----------------------------------------------------------------------------- > > Key: WFLY-67 > URL: https://issues.jboss.org/browse/WFLY-67 > Project: WildFly > Issue Type: Bug > Components: EJB > Environment: JBoss 7.2.0-Final Prerelease (Commit 4ed76c) and JBoss 7.1.3.Final on Win7/64 JDK 1.7.0_09 > Reporter: Robert Panzer > Assignee: Ondrej Zizka > Fix For: 8.0.0.Alpha1 > > Attachments: cmt-never-array-params.zip > > > It seems that the method-params for container transactions are not matched correctly if the contain arrays. > I've got an EJB "First" that calls another EJB "Second". Both have the same interface containing a method void test(String[]); > If I define the transaction attribute NEVER including method-params for "First" and without params for "Second" the test fails with > JBAS014163: Transaction present on server in Never call (EJB3 13.6.2.6) > I define the container transaction like this: > <container-transaction> > <method> > <ejb-name>FirstWithParams</ejb-name> > <method-intf>Local</method-intf> > <method-name>test</method-name> > <method-params> > <method-param>java.lang.String[]</method-param> > </method-params> > </method> > <method> > <ejb-name>FirstWithParams</ejb-name> > <method-intf>Local</method-intf> > <method-name>test</method-name> > <method-params> > <method-param>java.lang.String</method-param> > </method-params> > </method> > <method> > <ejb-name>FirstWithParams</ejb-name> > <method-intf>Local</method-intf> > <method-name>test</method-name> > <method-params> > <method-param>int</method-param> > </method-params> > </method> > <method> > <ejb-name>Second</ejb-name> > <method-intf>Local</method-intf> > <method-name>test</method-name> > </method> > <trans-attribute>Never</trans-attribute> > </container-transaction> > I will attach a test case that fails at the call to test(String[]) but successfully call test(String) and test(int). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2627) EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2627?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2627: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1180556, https://bugzilla.redhat.com/show_bug.cgi?id=1180570 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1180556) > EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior > -------------------------------------------------------------------------------------------- > > Key: WFLY-2627 > URL: https://issues.jboss.org/browse/WFLY-2627 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Environment: jdk1.7.0_45_x64, Windows 7 > Reporter: Norbert Bumm > Assignee: David Lloyd > Attachments: arquillian-jpa.zip, wildfly-src-7.2.0.Final-TransactionBug.patch > > > If there is a global transaction declaration for “Supports” and a “Required” declaration for a specific Method the “Required” gets ignored. I first encountered the problem with an old 2.1 EJB, but the problem is also there with a 3.1 EJB with deployment descriptor. It works correct with annotations. > ejb-jar.xml snippet > {code:xml} > <container-transaction> > <method> > <ejb-name>UserDAOImpl</ejb-name> > <method-name>*</method-name> > </method> > <trans-attribute>Supports</trans-attribute> > </container-transaction> > <container-transaction> > <method> > <ejb-name>UserDAOImpl</ejb-name> > <method-intf>Local</method-intf> > <method-name>createUser</method-name> > </method> > <trans-attribute>Required</trans-attribute> > </container-transaction> > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

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 January 2015