[JBoss JIRA] (WFLY-5633) Cannot load root node after domain start
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-5633?page=com.atlassian.jira.plugin.... ]
James Perkins reopened WFLY-5633:
---------------------------------
> Cannot load root node after domain start
> -----------------------------------------
>
> Key: WFLY-5633
> URL: https://issues.jboss.org/browse/WFLY-5633
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
>
> {code}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.008 sec <<< FAILURE! - in org.jboss.as.arquillian.container.domain.managed.test.ManagedDomainTestCase
> org.jboss.as.arquillian.container.domain.managed.test.ManagedDomainTestCase Time elapsed: 6.006 sec <<< ERROR!
> java.lang.RuntimeException: org.jboss.as.arquillian.container.domain.ManagementClient$UnSuccessfulOperationException: undefined
> at org.jboss.as.arquillian.container.domain.ManagementClient.lazyLoadRootNode(ManagementClient.java:390)
> at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:115)
> at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:126)
> at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (ELY-313) Add event notification API to realms
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-313?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-313:
---------------------------------
Fix Version/s: 1.1.0.Beta2
> Add event notification API to realms
> ------------------------------------
>
> Key: ELY-313
> URL: https://issues.jboss.org/browse/ELY-313
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.1.0.Beta2
>
>
> A realm may wish to take action in the event of a successful or failed authentication, or possibly other future events. Add a general infrastructure to realms to handle events.
> Ideally the implementation will be a single method which accepts an abstract RealmEvent object, whose concrete types will describe the various possible events.
> There should be a RealmEventVisitor class which allows multiple-dispatch style type discrimination.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5178) Intermittent failure: NullPointerException during undeployment
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-5178?page=com.atlassian.jira.plugin.... ]
Michal Vinkler commented on WFLY-5178:
--------------------------------------
The issue is still present in DR13:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> Intermittent failure: NullPointerException during undeployment
> --------------------------------------------------------------
>
> Key: WFLY-5178
> URL: https://issues.jboss.org/browse/WFLY-5178
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Richard Achmatowicz
> Labels: clean_undeploy
>
> Intermittent failure, so far seen in only one failover test for remote stateful EJBs:
> scenario ejb-ejbremote-undeploy-dist-async
> Setup: 4 node cluster, one node at time undeploys application (clusterbench-ee7.ear), while standalone clients keep calling the application.
> Just before server perf19 finished undeployment of the application, it logged this error 50 times:
> {code}
> [JBossINF] [0m[31m14:50:41,136 ERROR [org.jboss.as.ejb3.remote] (EJB default - 9) WFLYEJB0151: Exception while generating session id for component RemoteStatefulSBImpl with invocation id: -28551 on channel Channel ID 1ca843e6 (inbound) of Remoting connection 4b2907f9 to /10.16.90.52:58920: javax.ejb.EJBException: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSessionRemote(StatefulSessionComponent.java:263)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.SessionOpenRequestHandler$SessionIDGeneratorTask.run(SessionOpenRequestHandler.java:145)
> [JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [JBossINF] Caused by: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> [JBossINF] at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSessionRemote(StatefulSessionComponent.java:258)
> [JBossINF] ... 7 more
> {code}
> The other nodes did not log this error.
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-2102) Improve deployment annotation parsing error message
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2102?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-2102:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
(was: 10.0.0.Final)
> Improve deployment annotation parsing error message
> -----------------------------------------------------
>
> Key: WFLY-2102
> URL: https://issues.jboss.org/browse/WFLY-2102
> Project: WildFly
> Issue Type: Enhancement
> Components: EE
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 11.0.0.Alpha1
>
>
> Improve deployment annotation parsing error message
> Code such as this below, will error with IllegalArgumentException: Empty name segment is not allowed for env. The env is not enough information to identify what the issue is.
> @Singleton
> @Startup
> public class TestEJB {
> @Resource(name="/queue/test")
> private Queue queue;
> }
> Caused by: java.lang.IllegalArgumentException: Empty name segment is not allowed for env
> at org.jboss.msc.service.ServiceName.of(ServiceName.java:85) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at org.jboss.msc.service.ServiceName.append(ServiceName.java:112) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at org.jboss.as.naming.deployment.ContextNames.buildServiceName(ContextNames.java:183)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo.<init>(ContextNames.java:195)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo.<init>(ContextNames.java:186)
> at org.jboss.as.naming.deployment.ContextNames.bindInfoFor(ContextNames.java:141)
> at org.jboss.as.ee.component.OptionalLookupInjectionSource.getResourceValue(OptionalLookupInjectionSource.java:84)
> at org.jboss.as.ee.component.ComponentDescription$InjectedConfigurator.configureDependency(ComponentDescription.java:1019)
> at org.jboss.as.ee.component.ComponentDescription$InjectedConfigurator.configureDependency(ComponentDescription.java:998)
> at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deployComponent(ComponentInstallProcessor.java:138)
> at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:95)
> ... 6 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5212) IllegalStateException: no transaction associated with thread after undeploy
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-5212?page=com.atlassian.jira.plugin.... ]
Michal Vinkler commented on WFLY-5212:
--------------------------------------
[~pferraro] Sorry for not filling the version. I can still see this issue in EAP 7.0.0.DR13 (10.0.0.CR4), although this time the error was logged only on one server and only 3 times, right before the application was undeployed. Link:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
Another scenario where the error occured (also only 3 times on one server):
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> IllegalStateException: no transaction associated with thread after undeploy
> ---------------------------------------------------------------------------
>
> Key: WFLY-5212
> URL: https://issues.jboss.org/browse/WFLY-5212
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR4
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Minor
>
> Intermittent failure, so far seen in only this scenario:
> ejb-ejbservlet-undeploy-dist-sync
> Setup: 4 node cluster, one node at time undeploys application (clusterbench-ee7.ear), while standalone clients keep calling the application.
> Right after undeploying the application servers perf19,20,21 logged this error approx. 50 times:
> {code}
> [JBossINF] [0m[31m18:37:43,800 ERROR [io.undertow.request] (default task-111) UT005023: Exception handling request to /clusterbench/ejbservlet: java.lang.IllegalStateException: no transaction associated with thread
> [JBossINF] at org.infinispan.transaction.tm.DummyBaseTransactionManager.rollback(DummyBaseTransactionManager.java:94)
> [JBossINF] at org.wildfly.clustering.ee.infinispan.ActiveTransactionBatch.discard(ActiveTransactionBatch.java:57)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:131)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:725)
> [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:367)
> [JBossINF] at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
> [JBossINF] at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:231)
> [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:281)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5393) Using deprecated attribute use-hornetq-store in CLI does not have any effect being set
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5393?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka commented on WFLY-5393:
----------------------------------------
Hi Amos,
that's my understanding of deprecated attributes. I think that even it's deprecated it should work - e.g. bypass the call.
> Using deprecated attribute use-hornetq-store in CLI does not have any effect being set
> --------------------------------------------------------------------------------------
>
> Key: WFLY-5393
> URL: https://issues.jboss.org/browse/WFLY-5393
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.0.0.CR1
> Reporter: Ondřej Chaloupka
> Assignee: Amos Feng
> Fix For: 10.0.0.Final
>
>
> Attribute {{use-hornetq-store}} was deprecated for EAP7 and {{use-journal-store}} should be used instead. But even the attribute is deprecated it still should provide its old functionality.
> I think that using {{use-hornetq-store}} would have the same effect as when {{use-journal-store}} is used.
> I would think that when one of the attribute is set then the other one should present the same settings.
> {code}
> /subsystem=transactions:read-attribute(name=use-hornetq-store)
> {
> "outcome" => "success",
> "result" => false
> }
> /subsystem=transactions:read-attribute(name=use-journal-store)
> {
> "outcome" => "success",
> "result" => false
> }
> /subsystem=transactions:write-attribute(name=use-journal-store, value=true)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-restart" => true,
> "process-state" => "restart-required"
> }
> }
> :shutdown(restart=true)
> {"outcome" => "success"}
> /subsystem=transactions:read-attribute(name=use-journal-store)
> {
> "outcome" => "success",
> "result" => true
> }
> /subsystem=transactions:read-attribute(name=use-hornetq-store)
> {
> "outcome" => "success",
> "result" => false
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5212) IllegalStateException: no transaction associated with thread after undeploy
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-5212?page=com.atlassian.jira.plugin.... ]
Michal Vinkler updated WFLY-5212:
---------------------------------
Affects Version/s: 10.0.0.CR4
> IllegalStateException: no transaction associated with thread after undeploy
> ---------------------------------------------------------------------------
>
> Key: WFLY-5212
> URL: https://issues.jboss.org/browse/WFLY-5212
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR4
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Minor
>
> Intermittent failure, so far seen in only this scenario:
> ejb-ejbservlet-undeploy-dist-sync
> Setup: 4 node cluster, one node at time undeploys application (clusterbench-ee7.ear), while standalone clients keep calling the application.
> Right after undeploying the application servers perf19,20,21 logged this error approx. 50 times:
> {code}
> [JBossINF] [0m[31m18:37:43,800 ERROR [io.undertow.request] (default task-111) UT005023: Exception handling request to /clusterbench/ejbservlet: java.lang.IllegalStateException: no transaction associated with thread
> [JBossINF] at org.infinispan.transaction.tm.DummyBaseTransactionManager.rollback(DummyBaseTransactionManager.java:94)
> [JBossINF] at org.wildfly.clustering.ee.infinispan.ActiveTransactionBatch.discard(ActiveTransactionBatch.java:57)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:131)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:725)
> [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:367)
> [JBossINF] at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
> [JBossINF] at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:231)
> [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:281)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-276) Clustering/multi-node tests cannot be run with -Djpda debugger
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-276?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar reassigned WFLY-276:
-----------------------------------
Assignee: Paul Ferraro (was: Ondrej Zizka)
> Clustering/multi-node tests cannot be run with -Djpda debugger
> --------------------------------------------------------------
>
> Key: WFLY-276
> URL: https://issues.jboss.org/browse/WFLY-276
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Documentation, Test Suite
> Affects Versions: 8.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Minor
>
> The doc now says whats pasted below, but I am not sure if both servers are listening on 8787 because (that would fail the startup), if I have to connect to both or where do I configure that, etc.
> {code}
> Running JBoss AS instances with debugger
> Adding -Djpda (May be changed to -Ddebug in the future) will make JBoss AS run with JPDA JVM arguments for debugging.
> It will suspend and wait for the debugger to connect at port 8787.
> JBoss AS is started by Arquillian, when the first test which requires given instance is run. There's (currently) no challenge text in the console, it will look like the first test is stuck. This is being solved in http://jira.codehaus.org/browse/SUREFIRE-781.
> Depending on which test group(s) you run, multiple instances may be started. In that case, you need to attach the debugger multiple times.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-276) Clustering/multi-node tests cannot be run with -Djpda debugger
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-276?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar reassigned WFLY-276:
-----------------------------------
Assignee: (was: Paul Ferraro)
> Clustering/multi-node tests cannot be run with -Djpda debugger
> --------------------------------------------------------------
>
> Key: WFLY-276
> URL: https://issues.jboss.org/browse/WFLY-276
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Documentation, Test Suite
> Affects Versions: 8.0.0.Alpha1
> Reporter: Radoslav Husar
> Priority: Minor
>
> The doc now says whats pasted below, but I am not sure if both servers are listening on 8787 because (that would fail the startup), if I have to connect to both or where do I configure that, etc.
> {code}
> Running JBoss AS instances with debugger
> Adding -Djpda (May be changed to -Ddebug in the future) will make JBoss AS run with JPDA JVM arguments for debugging.
> It will suspend and wait for the debugger to connect at port 8787.
> JBoss AS is started by Arquillian, when the first test which requires given instance is run. There's (currently) no challenge text in the console, it will look like the first test is stuck. This is being solved in http://jira.codehaus.org/browse/SUREFIRE-781.
> Depending on which test group(s) you run, multiple instances may be started. In that case, you need to attach the debugger multiple times.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months