November 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1140) Support provisioning from a deployment

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-1140?page=com.atlassian.jira.plugin.... ] Thomas Diesler resolved WFLY-1140. ---------------------------------- Resolution: Out of Date Out of Date > Support provisioning from a deployment > -------------------------------------- > > Key: WFLY-1140 > URL: https://issues.jboss.org/browse/WFLY-1140 > Project: WildFly > Issue Type: Feature Request > Components: Server > Reporter: Thomas Diesler > Assignee: Jason Greene > > This is currently not possible because it creates a nested management op, which deadlocks. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-893) Undeploy failure after deployment failure for ARQ tests

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-893?page=com.atlassian.jira.plugin.s... ] Thomas Diesler resolved WFLY-893. --------------------------------- Resolution: Out of Date Out of Date > Undeploy failure after deployment failure for ARQ tests > ------------------------------------------------------- > > Key: WFLY-893 > URL: https://issues.jboss.org/browse/WFLY-893 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Thomas Diesler > Assignee: Andrew Rubinger > > {code} > 04:22:14,469 INFO [org.jboss.as.server.deployment] (pool-2-thread-1) Content added at location /home/ondra/work/AS-7/ozizka-as7/testsuite/integration/target/jbossas/standalone/data/content/bf/815f1962565545e298089d58c3988d770833cb/content > 04:22:14,470 INFO [org.jboss.as.server.deployment] (MSC service thread 1-10) Starting deployment of "resteasy-osgi-client.war" > 04:22:14,677 INFO [org.jboss.as.server.controller] (pool-2-thread-1) Deployment of "resteasy-osgi-client.war" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"resteasy-osgi-client.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.osgi.cmpn\".\"4.2.0.200908310645\" ]"]} > 04:22:14,678 INFO [org.jboss.as.server.deployment] (MSC service thread 1-10) Stopped deployment resteasy-osgi-client.war in 1ms > 04:22:14,685 ERROR [org.jboss.as.controller] (pool-2-thread-1) Operation ("undeploy") failed - address: ([("deployment" => "resteasy-osgi-client.war")]): java.util.NoSuchElementException: No child 'runtime-name' exists > at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:362) [jboss-dmr-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.dmr.ModelNode.require(ModelNode.java:703) [jboss-dmr-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.as.server.deployment.DeploymentUndeployHandler.execute(DeploymentUndeployHandler.java:58) > {code} > The test correctly fails with a deploy error including the cause > {code} > ------------------------------------------------------------------------------- > Test set: org.jboss.as.test.integration.osgi.jaxrs.RestEasyIntegrationTestCase > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 8.036 sec <<< FAILURE! > org.jboss.as.test.integration.osgi.jaxrs.RestEasyIntegrationTestCase Time elapsed: 0 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.DeploymentException: Could not deploy to container > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:58) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:111) > ... > Caused by: java.lang.Exception: {"Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"resteasy-osgi-client.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.osgi.cmpn\".\"4.2.0.200908310645\" ]"]} > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:99) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:88) > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2275) StackOverflowError on DataSource resource injection

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-2275?page=com.atlassian.jira.plugin.... ] Thomas Diesler resolved WFLY-2275. ---------------------------------- Resolution: Out of Date Out of Date > StackOverflowError on DataSource resource injection > --------------------------------------------------- > > Key: WFLY-2275 > URL: https://issues.jboss.org/browse/WFLY-2275 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 8.0.0.Beta1 > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Attachments: standalone-osgi.xml > > > {code} > @Resource(name="java:comp/DefaultDataSource") > public DataSource ds; > {code} > leads to > {code} > 10:59:21,901 INFO [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011001: Bundle installed: resource-injection.jar:0.0.0 > 10:59:21,937 INFO [org.jboss.as.arquillian] (MSC service thread 1-3) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config."resource-injection.jar",unit=resource-injection.jar,tests=[org.jboss.test.osgi.example.resource.ResourceInjectionTestCase]] > 10:59:21,993 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."resource-injection.jar".Activate: org.jboss.msc.service.StartException in service jboss.deployment.unit."resource-injection.jar".Activate: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > Caused by: java.lang.StackOverflowError > at java.util.Vector.<init>(Vector.java:127) [rt.jar:1.7.0_25] > at java.util.Vector.<init>(Vector.java:144) [rt.jar:1.7.0_25] > at java.util.Vector.<init>(Vector.java:153) [rt.jar:1.7.0_25] > at javax.naming.NameImpl.<init>(NameImpl.java:273) [rt.jar:1.7.0_25] > at javax.naming.NameImpl.<init>(NameImpl.java:277) [rt.jar:1.7.0_25] > at javax.naming.CompositeName.<init>(CompositeName.java:231) [rt.jar:1.7.0_25] > at org.jboss.as.naming.util.NameParser.parse(NameParser.java:49) > at org.jboss.as.naming.NamingContext.parseName(NamingContext.java:496) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) > at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) > at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) > at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81) > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1897) ENCRYPT might drop messages during key change

by Tero Leppikangas (JIRA)

[ https://issues.jboss.org/browse/JGRP-1897?page=com.atlassian.jira.plugin.... ] Tero Leppikangas commented on JGRP-1897: ---------------------------------------- Oh, my initial solution is here: https://github.com/tepitebson/JGroups/tree/ENCRYPT_queue_on_new_cipher > ENCRYPT might drop messages during key change > --------------------------------------------- > > Key: JGRP-1897 > URL: https://issues.jboss.org/browse/JGRP-1897 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > > ENCRYPT might drop some (unicast) messages encrypted with unknown key if the delivery of new view is delayed. > This problem was noticed while doing some stress testing on the fix for JGRP-1893. > When view changes, coordinator multicasts the new view after which is starts using new symmetric keys. If some node receives a message sent with the new key before the new view is received, the received message will be dropped since it cannot be decrypted. > We thought of possible solutions to be. > 1. Sender specific queue holding the messages received. > 2. Starting to queue up messages until new view has been received > I have implemented the second option which is quite straightforward, but it could lead into problems when receiving message with unknown key that is not related to coming view change. > I wonder if there is another way to overcome this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1897) ENCRYPT might drop messages during key change

by Tero Leppikangas (JIRA)

Tero Leppikangas created JGRP-1897: -------------------------------------- Summary: ENCRYPT might drop messages during key change Key: JGRP-1897 URL: https://issues.jboss.org/browse/JGRP-1897 Project: JGroups Issue Type: Bug Reporter: Tero Leppikangas Assignee: Bela Ban ENCRYPT might drop some (unicast) messages encrypted with unknown key if the delivery of new view is delayed. This problem was noticed while doing some stress testing on the fix for JGRP-1893. When view changes, coordinator multicasts the new view after which is starts using new symmetric keys. If some node receives a message sent with the new key before the new view is received, the received message will be dropped since it cannot be decrypted. We thought of possible solutions to be. 1. Sender specific queue holding the messages received. 2. Starting to queue up messages until new view has been received I have implemented the second option which is quite straightforward, but it could lead into problems when receiving message with unknown key that is not related to coming view change. I wonder if there is another way to overcome this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-112: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1149618, https://bugzilla.redhat.com/show_bug.cgi?id=1149623, https://bugzilla.redhat.com/show_bug.cgi?id=1149621 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1149618, https://bugzilla.redhat.com/show_bug.cgi?id=1149623) > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 1139202|https://bugzilla.redhat.com/show_bug.cgi?id=1139202] from ASSIGNED to MODIFIED > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-211) HC is over eager to remove its content

by Emmanuel Hugonnet (JIRA)

Emmanuel Hugonnet created WFCORE-211: ---------------------------------------- Summary: HC is over eager to remove its content Key: WFCORE-211 URL: https://issues.jboss.org/browse/WFCORE-211 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha10 Reporter: Emmanuel Hugonnet Assignee: Emmanuel Hugonnet Priority: Minor If you deploy the same war twice (same hash with different names) on a domain then undeploy one the content is removed from the HC while it is still referenced and potentially useable. The content is not removed from the servers content directory. To reproduce : deploy /home/ehsavoie/dev/wildfly/quickstart/ejb-in-war/target/wildfly-ejb-in-war.war --runtime-name=first.war --server-groups=main-server-group --name=first.war deploy /home/ehsavoie/dev/wildfly/quickstart/ejb-in-war/target/wildfly-ejb-in-war.war --runtime-name=second.war --server-groups=main-server-group --name=second.war undeploy first.war --all-relevant-server-groups -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4045) Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue

by Josef Cacek (JIRA)

Josef Cacek created WFLY-4045: --------------------------------- Summary: Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue Key: WFLY-4045 URL: https://issues.jboss.org/browse/WFLY-4045 Project: WildFly Issue Type: Enhancement Components: Test Suite Reporter: Josef Cacek Assignee: Josef Cacek Add a regression test for https://issues.jboss.org/browse/WFCORE-190 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1893) ENCRYPT: Thread safety issues during key changes

by Tero Leppikangas (JIRA)

[ https://issues.jboss.org/browse/JGRP-1893?page=com.atlassian.jira.plugin.... ] Tero Leppikangas commented on JGRP-1893: ---------------------------------------- I believe that the implementation has been the same from Java 6 (http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-...) and the implementation is the same in Java 8 (also with Sun's own JDK) The problem is that for multicast use, the ip_ttl is vital part of the configuration, thus cannot be removed from the config. Although the issue causes no problems, it is not nice to have such an exception printed out on every init of a stack. If the discussion about the TTL issue continues, I suppose the proper place for the conversation is under JGRP-1880. > ENCRYPT: Thread safety issues during key changes > ------------------------------------------------ > > Key: JGRP-1893 > URL: https://issues.jboss.org/browse/JGRP-1893 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > > For symmetric encryption, ENCRYPT has members with shared state: secret key, version and ciphers. In order for to provide consistent state between different threads accessing these members, they should be synchronized. > I have implemented one solution by wrapping the state in separate object which can be found here: > https://github.com/tepitebson/JGroups/tree/ENCRYPT_Thread_safety > I also have replaced the WeakHashMap holding the previous keys with Cache in google's guava library so my solution probably is not suitable for an official solution. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 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 November 2014