November 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-378) Provide ability to detect server shutdown

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-378?page=com.atlassian.jira.plugin.s... ] Thomas Diesler resolved WFLY-378. --------------------------------- Resolution: Out of Date Fix Version/s: (was: 9.0.0.Beta1) Out of Date > Provide ability to detect server shutdown > ----------------------------------------- > > Key: WFLY-378 > URL: https://issues.jboss.org/browse/WFLY-378 > Project: WildFly > Issue Type: Feature Request > Components: Server > Reporter: Thomas Diesler > Assignee: Jason Greene > > The general use case is that a subsystem maintains state (on behalf of a deployment) that should be removed on explicit user interaction (i.e. mgmt op) but not on subsystem/server shutdown. This should also work in the domain case. Perhaps the ApplicationServerService (or similar) could be queried about whether it is currently shutting down. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1041) Add support for deployment triggered by another management operation

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-1041?page=com.atlassian.jira.plugin.... ] Thomas Diesler resolved WFLY-1041. ---------------------------------- Resolution: Out of Date Out of Date > Add support for deployment triggered by another management operation > -------------------------------------------------------------------- > > Key: WFLY-1041 > URL: https://issues.jboss.org/browse/WFLY-1041 > Project: WildFly > Issue Type: Feature Request > Components: Server > Reporter: Thomas Diesler > Assignee: Jason Greene > > This is related to [Provisioner service and Feature deployment|https://community.jboss.org/wiki/ProvisionerServiceAndFeatureD...] > If I remember correctly we cannot have nested management operations. A deployment being a management op can therefore not trigger another deployment op, right? > The general use case is that during deployment of A I want to deploy B which is required by A. Even more general - a user invoked mgmnt op should be able to trigger a deployment op. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1195) Provide embedded EJB3 test coverage

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-1195?page=com.atlassian.jira.plugin.... ] Thomas Diesler resolved WFLY-1195. ---------------------------------- Resolution: Out of Date Out of Date > Provide embedded EJB3 test coverage > ----------------------------------- > > Key: WFLY-1195 > URL: https://issues.jboss.org/browse/WFLY-1195 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Thomas Diesler > > The TCK runs into issues with embedded EJB that are not caught by the AS7 test suite. Basic smoke testing should be provided. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1928) jboss-as-standalone.sh does not work on MacOS

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-1928?page=com.atlassian.jira.plugin.... ] Thomas Diesler resolved WFLY-1928. ---------------------------------- Resolution: Out of Date Fix Version/s: (was: Awaiting Volunteers) Out of Date > jboss-as-standalone.sh does not work on MacOS > --------------------------------------------- > > Key: WFLY-1928 > URL: https://issues.jboss.org/browse/WFLY-1928 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.0.0.Alpha4 > Reporter: Thomas Diesler > > {code} > FuseFabric:karaf@root> process-start root 3 > bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory > Error executing command: [bin/init.d/jboss-as-standalone.sh, start] exited with 1 > bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[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)

10 years, 1 month

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)

10 years, 1 month

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)

10 years, 1 month

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)

10 years, 1 month

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)

10 years, 1 month

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)

10 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2014