April 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-316) Slave host does not register to DC when starting with --cached-dc and DC is available

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-316?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-316: ------------------------------------ Fix Version/s: 3.0.0.Beta1 > Slave host does not register to DC when starting with --cached-dc and DC is available > ------------------------------------------------------------------------------------- > > Key: WFCORE-316 > URL: https://issues.jboss.org/browse/WFCORE-316 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Manel Martinez Gonzalez > Assignee: Ken Wills > Fix For: 3.0.0.Beta1 > > > NOTE: this is related to AS7-4281 (see https://issues.jboss.org/browse/AS7-4281?focusedCommentId=12682058&page=c... ) > When a slave host is started with --cached-dc option it won't register to Domain Controller although it's available. domain.sh help says "If this host is not the Domain Controller and cannot contact the Domain Controller at boot, boot using a locally cached copy of the domain configuration (see --backup)" and this is not really happening because slave host never contact to DC with --cached-dc -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-316) Slave host does not register to DC when starting with --cached-dc and DC is available

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-316?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-316: ----------------------------------------- [~luck3y] I poked at this a bit and https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... looks like the basis of a proper semantic. A slave always tries to contact the DC and falls back to the cached domain config only if it fails. In that case, post-boot it installs a service that begins periodically trying to discover the DC again. It kinda works, but 1) Once it joins domain management doesn't work right. All ops against the DC that would get propagated to the slave fail with an ArrayIndexOutOfBoundsException. 2) The persistence of domain.xml on the slave is broken; i.e. it won't persist changes back to domain.cached-remote.xml. It needs to because if the DC connection goes away and then the slave is reloaded it needs to reload to the last good state. 3) Interaction with --backup needs tweaking in general. IIRC we fail if both --backup and --cached-dc are set, and that no longer makes sense with this approach. 3) There are some test failures in AdminOnlyPolicyTestCase 4) Other stuff I'm sure I haven't thought about or noticed. ;) Still, unless 1) turns out to be some kind of really hard problem, this seems like something we can get done, so I'm going to schedule it. > Slave host does not register to DC when starting with --cached-dc and DC is available > ------------------------------------------------------------------------------------- > > Key: WFCORE-316 > URL: https://issues.jboss.org/browse/WFCORE-316 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Manel Martinez Gonzalez > Assignee: Ken Wills > Fix For: 3.0.0.Beta1 > > > NOTE: this is related to AS7-4281 (see https://issues.jboss.org/browse/AS7-4281?focusedCommentId=12682058&page=c... ) > When a slave host is started with --cached-dc option it won't register to Domain Controller although it's available. domain.sh help says "If this host is not the Domain Controller and cannot contact the Domain Controller at boot, boot using a locally cached copy of the domain configuration (see --backup)" and this is not really happening because slave host never contact to DC with --cached-dc -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBEE-160) jboss-transaction-api OSGi bundle requiring optional packages

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/JBEE-160?page=com.atlassian.jira.plugin.s... ] Brett Meyer commented on JBEE-160: ---------------------------------- [~ctomc], looks good, thanks > jboss-transaction-api OSGi bundle requiring optional packages > ------------------------------------------------------------- > > Key: JBEE-160 > URL: https://issues.jboss.org/browse/JBEE-160 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-transaction-api > Reporter: Brett Meyer > Assignee: Tomaz Cerar > > The jboss-transaction-api_1.2_spec OSGi bundle requires the 'javax.enterprise.context'. Instead, that should be optional, right? cdi-api shouldn't be required to simply use jta. Thanks! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2057) Message bundler improvements

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2057?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2057: -------------------------------- Test with UPerf, MPerf, IspnPerfTest > Message bundler improvements > ---------------------------- > > Key: JGRP-2057 > URL: https://issues.jboss.org/browse/JGRP-2057 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > * {{SingletonAddress}} is not needed anymore as we removed the shared transport in 4.0 > ** This slows down the bundler as it is used as key to the bundler hashmaps > * {{SenderSendsBundler}}: send messages outside the lock scope. This requires us to use a number of bundler hashmaps, or making a shallow copy of the buckets of the current hashmap, before clearing it -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2057) Message bundler improvements

by Bela Ban (JIRA)

Bela Ban created JGRP-2057: ------------------------------ Summary: Message bundler improvements Key: JGRP-2057 URL: https://issues.jboss.org/browse/JGRP-2057 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0 * {{SingletonAddress}} is not needed anymore as we removed the shared transport in 4.0 ** This slows down the bundler as it is used as key to the bundler hashmaps * {{SenderSendsBundler}}: send messages outside the lock scope. This requires us to use a number of bundler hashmaps, or making a shallow copy of the buckets of the current hashmap, before clearing it -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-5593) VaultTool does not support KeySize != 128

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/WFLY-5593?page=com.atlassian.jira.plugin.... ] Hynek Švábek commented on WFLY-5593: ------------------------------------ Hi, It works for me. But you need OpenJDK or others JDK with Java Cryptography Extension (JCE). I noticed one problem there: I have to use same value for params *"-storepass PASSWORD -keypass PASSWORD"* otherwise I get same exception as above: PBOX00137: Security Vault does not contain SecretKey entry under alias (vault) > VaultTool does not support KeySize != 128 > ----------------------------------------- > > Key: WFLY-5593 > URL: https://issues.jboss.org/browse/WFLY-5593 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.CR4 > Reporter: Andreas Weise > Assignee: Darran Lofthouse > Priority: Minor > > Vault tool (vault.sh) returns exception PBOX00137: Security Vault does not contain SecretKey entry under alias (vault) when using a JCEKS with AES 256. > It seems only 128 Bit Key Length is supported by the Vault Tool, which is default in [org/picketbox/plugins/vault/PicketBoxSecurityVault.java|https://github.co...] > Key length could be parametrized in PicketBoxSecurityVault, but vault tool does not support this, more specifically [org/jboss/as/security/vault/VaultSession.getVaultOptionsMap()|https://git...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-5593) VaultTool does not support KeySize != 128

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/WFLY-5593?page=com.atlassian.jira.plugin.... ] Hynek Švábek edited comment on WFLY-5593 at 4/25/16 6:59 AM: ------------------------------------------------------------- Hi, It works for me for AES 256. But you need OpenJDK or others JDK with Java Cryptography Extension (JCE). I noticed one problem there: I have to use same value for params *"-storepass PASSWORD -keypass PASSWORD"* otherwise I get same exception as above: PBOX00137: Security Vault does not contain SecretKey entry under alias (vault) was (Author: hsvabek): Hi, It works for me. But you need OpenJDK or others JDK with Java Cryptography Extension (JCE). I noticed one problem there: I have to use same value for params *"-storepass PASSWORD -keypass PASSWORD"* otherwise I get same exception as above: PBOX00137: Security Vault does not contain SecretKey entry under alias (vault) > VaultTool does not support KeySize != 128 > ----------------------------------------- > > Key: WFLY-5593 > URL: https://issues.jboss.org/browse/WFLY-5593 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.CR4 > Reporter: Andreas Weise > Assignee: Darran Lofthouse > Priority: Minor > > Vault tool (vault.sh) returns exception PBOX00137: Security Vault does not contain SecretKey entry under alias (vault) when using a JCEKS with AES 256. > It seems only 128 Bit Key Length is supported by the Vault Tool, which is default in [org/picketbox/plugins/vault/PicketBoxSecurityVault.java|https://github.co...] > Key length could be parametrized in PicketBoxSecurityVault, but vault tool does not support this, more specifically [org/jboss/as/security/vault/VaultSession.getVaultOptionsMap()|https://git...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1288) installing CP over one-off fails if the modules patched by the one-off are not patched in the CP

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1288?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1288: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1295999|https://bugzilla.redhat.com/show_bug.cgi?id=1295999] from MODIFIED to ON_QA > installing CP over one-off fails if the modules patched by the one-off are not patched in the CP > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-1288 > URL: https://issues.jboss.org/browse/WFCORE-1288 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 1.0.1.Final > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Priority: Critical > Fix For: 2.0.8.Final > > > If a CP is installed over active one-off patches, the patch application may fail if the CP does not contain updates for the modules that were patched by the one-offs. > Normally, CP patches accumulate the one-off patches released since the previous CP which is, probably, why this bug has not been discovered for a long time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6117) Modify javax.transaction.api to exclude the .xa subpackage

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6117?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6117: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1309174|https://bugzilla.redhat.com/show_bug.cgi?id=1309174] from MODIFIED to ON_QA > Modify javax.transaction.api to exclude the .xa subpackage > ---------------------------------------------------------- > > Key: WFLY-6117 > URL: https://issues.jboss.org/browse/WFLY-6117 > Project: WildFly > Issue Type: Task > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 10.1.0.Final > > > Simultaneously with the core upgrade which includes WFCORE-1357, update the module definition for {{javax.transaction.api}} to exclude the {{javax/transaction/xa}} package from the artifact, instead re-exporting it from the JDK. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6104) Too many invocations to a remote EJB from multiple threads cause infinite wait

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6104?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6104: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1302181|https://bugzilla.redhat.com/show_bug.cgi?id=1302181] from MODIFIED to ON_QA > Too many invocations to a remote EJB from multiple threads cause infinite wait > ------------------------------------------------------------------------------ > > Key: WFLY-6104 > URL: https://issues.jboss.org/browse/WFLY-6104 > Project: WildFly > Issue Type: Bug > Components: Remoting > Affects Versions: 10.0.0.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > https://bugzilla.redhat.com/show_bug.cgi?id=1302181 > While a thread (1) of EJB client invokes a remote EJB which needs long > processing time and wait for the response, if the other threads complete > more than 65536 invocations to the remote EJB, EJBCLIENT000011 message like > below occurs in EJB client side and the waiting thread (1) falls into > infinite wait for the response. > INFO: EJBCLIENT000011: Discarding result for invocation id 0 since no > waiting context found > All invocations should successfully complete regardless of the number of > invocations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

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 April 2016