March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-576) Upgrade jboss-remoting to release that has fix for REM3-204

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-576?page=com.atlassian.jira.plugin... ] Tomaz Cerar updated WFCORE-576: ------------------------------- Summary: Upgrade jboss-remoting to release that has fix for REM3-204 (was: Upgrade jboss-remoting to 4.0.8.Final) > Upgrade jboss-remoting to release that has fix for REM3-204 > ----------------------------------------------------------- > > Key: WFCORE-576 > URL: https://issues.jboss.org/browse/WFCORE-576 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Test Suite > Affects Versions: 1.0.0.Alpha19 > Reporter: ehsavoie Hugonnet > Assignee: Tomaz Cerar > Fix For: 1.0.0.Beta1 > > > In order to fix WFCORE-487 we need to have a new version of jboss-remoting with the fix for REM3-204 integrated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-576) Upgrade jboss-remoting to release that has fix for REM3-204

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-576?page=com.atlassian.jira.plugin... ] Tomaz Cerar reassigned WFCORE-576: ---------------------------------- Assignee: David Lloyd (was: Tomaz Cerar) > Upgrade jboss-remoting to release that has fix for REM3-204 > ----------------------------------------------------------- > > Key: WFCORE-576 > URL: https://issues.jboss.org/browse/WFCORE-576 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Test Suite > Affects Versions: 1.0.0.Alpha19 > Reporter: ehsavoie Hugonnet > Assignee: David Lloyd > Fix For: 1.0.0.Beta1 > > > In order to fix WFCORE-487 we need to have a new version of jboss-remoting with the fix for REM3-204 integrated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-576) Upgrade jboss-remoting to release that has fix for REM3-204

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-576?page=com.atlassian.jira.plugin... ] Tomaz Cerar updated WFCORE-576: ------------------------------- Fix Version/s: 1.0.0.Beta1 > Upgrade jboss-remoting to release that has fix for REM3-204 > ----------------------------------------------------------- > > Key: WFCORE-576 > URL: https://issues.jboss.org/browse/WFCORE-576 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Test Suite > Affects Versions: 1.0.0.Alpha19 > Reporter: ehsavoie Hugonnet > Assignee: David Lloyd > Fix For: 1.0.0.Beta1 > > > In order to fix WFCORE-487 we need to have a new version of jboss-remoting with the fix for REM3-204 integrated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-576) Upgrade jboss-remoting to release that has fix for REM3-204

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-576?page=com.atlassian.jira.plugin... ] Tomaz Cerar commented on WFCORE-576: ------------------------------------ That will help us greatly with stability of few tests > Upgrade jboss-remoting to release that has fix for REM3-204 > ----------------------------------------------------------- > > Key: WFCORE-576 > URL: https://issues.jboss.org/browse/WFCORE-576 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Test Suite > Affects Versions: 1.0.0.Alpha19 > Reporter: ehsavoie Hugonnet > Assignee: David Lloyd > Fix For: 1.0.0.Beta1 > > > In order to fix WFCORE-487 we need to have a new version of jboss-remoting with the fix for REM3-204 integrated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-576) Upgrade jboss-remoting to 4.0.8.Final

by ehsavoie Hugonnet (JIRA)

ehsavoie Hugonnet created WFCORE-576: ---------------------------------------- Summary: Upgrade jboss-remoting to 4.0.8.Final Key: WFCORE-576 URL: https://issues.jboss.org/browse/WFCORE-576 Project: WildFly Core Issue Type: Component Upgrade Components: Test Suite Affects Versions: 1.0.0.Alpha19 Reporter: ehsavoie Hugonnet Assignee: Tomaz Cerar In order to fix WFCORE-487 we need to have a new version of jboss-remoting with the fix for REM3-204 integrated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-310) Allow servlets to be marked overridable via Servlet registration API

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-310?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-310: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1196513|https://bugzilla.redhat.com/show_bug.cgi?id=1196513] from NEW to ASSIGNED > Allow servlets to be marked overridable via Servlet registration API > -------------------------------------------------------------------- > > Key: JBWEB-310 > URL: https://issues.jboss.org/browse/JBWEB-310 > Project: JBoss Web > Issue Type: Enhancement > Affects Versions: JBossWeb-7.5.0.GA > Reporter: James Livingston > Assignee: Remy Maucherat > Attachments: JBWEB-310.patch > > > To resolve https://bugzilla.redhat.com/show_bug.cgi?id=1094248, JBossWeb needs to add an 'overridable' flag on Wrapper, and not treat new mappings as conflicting if the one previously using the mapping was marked overridable. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-227) RejectedExecutionException when closing ModelControllerClient client

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-227?page=com.atlassian.jira.plugin... ] Chao Wang reassigned WFCORE-227: -------------------------------- Assignee: Chao Wang (was: David Lloyd) > RejectedExecutionException when closing ModelControllerClient client > -------------------------------------------------------------------- > > Key: WFCORE-227 > URL: https://issues.jboss.org/browse/WFCORE-227 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Remoting > Affects Versions: 1.0.0.Alpha11 > Reporter: Alessio Soldano > Assignee: Chao Wang > Fix For: 1.0.0.Alpha15 > > > After wildfly-core 1.0.0.Alpha11 has been included in WFLY master, I'm seeing hundreds of the following exceptions in the logs when running the JBossWS-CXF testsuite: > {noformat} > Exception in thread "Remoting "management-client" task-4" java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteConnectionChannel$3@5651c0c2 rejected from org.xnio.XnioWorker$TaskPool@11462cd4[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 4] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) > at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372) > at org.xnio.XnioWorker.execute(XnioWorker.java:741) > at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:363) > at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:107) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {noformat} > The exception is logged just after the org.jboss.as.webservices.deployer.RemoteDeployer calls the RemotingModelControllerClient#close method. > The issue seems to be related to some kind of race condition, as trying to reproduce it with an attached debugger is not possible. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-227) RejectedExecutionException when closing ModelControllerClient client

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-227?page=com.atlassian.jira.plugin... ] Chao Wang reassigned WFCORE-227: -------------------------------- Assignee: David Lloyd (was: Chao Wang) > RejectedExecutionException when closing ModelControllerClient client > -------------------------------------------------------------------- > > Key: WFCORE-227 > URL: https://issues.jboss.org/browse/WFCORE-227 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Remoting > Affects Versions: 1.0.0.Alpha11 > Reporter: Alessio Soldano > Assignee: David Lloyd > Fix For: 1.0.0.Alpha15 > > > After wildfly-core 1.0.0.Alpha11 has been included in WFLY master, I'm seeing hundreds of the following exceptions in the logs when running the JBossWS-CXF testsuite: > {noformat} > Exception in thread "Remoting "management-client" task-4" java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteConnectionChannel$3@5651c0c2 rejected from org.xnio.XnioWorker$TaskPool@11462cd4[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 4] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) > at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372) > at org.xnio.XnioWorker.execute(XnioWorker.java:741) > at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:363) > at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:107) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {noformat} > The exception is logged just after the org.jboss.as.webservices.deployer.RemoteDeployer calls the RemotingModelControllerClient#close method. > The issue seems to be related to some kind of race condition, as trying to reproduce it with an attached debugger is not possible. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1907) ENCRYPT: asymmetric encryption fails on merge

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1907?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1907: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1187193|https://bugzilla.redhat.com/show_bug.cgi?id=1187193] from POST to MODIFIED > ENCRYPT: asymmetric encryption fails on merge > --------------------------------------------- > > Key: JGRP-1907 > URL: https://issues.jboss.org/browse/JGRP-1907 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.2 > > Attachments: encrypt.xml, EncryptKeyStore.xml > > > {{ENCRYPT}} fails to communicate after a network split and subsequent merge with asymmetric encryption. This works with symmetric encryption. > To reproduce: > * Members A and B > * Add {{<DISCARD use_gui="true"/>}} on top of {{UDP}} > * Form cluster {{(A,B)}} > * Create a network split: {{(A)}} and {{(B)}} > * Remove the network split > * Observe that with both symmetric and asymmetric encryption, the merge forms cluster {{(A,B)}} > * However, with asymmetric encryption, {{ENCRYPT}} fails to process any messages and rejects all messages, whereas with symmetric encryption, this works. > * Symmetric encryption: {{EncryptKeyStore.xml}} > * Asymmetric encryption: {{encrypt.xml}} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1119) Assign an unique NodeID automatically

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.... ] Amos Feng commented on WFLY-1119: --------------------------------- https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes... {code} public static final int NODE_NAME_SIZE = 28; {code} It looks like that the max length of thenode_identifier 24 is OK. > Assign an unique NodeID automatically > ------------------------------------- > > Key: WFLY-1119 > URL: https://issues.jboss.org/browse/WFLY-1119 > Project: WildFly > Issue Type: Feature Request > Components: Transactions > Reporter: Clebert Suconic > Assignee: Amos Feng > Priority: Optional > > It shouldn't be needed to assign the node-id manually IMO. > You could store the node-id on a file and recover it for subsequent starts. > On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file. > In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 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 March 2015