[JBoss JIRA] (WFCORE-769) Boot errors should hide the failure description if the failing operation address is not accessible
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-769?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet updated WFCORE-769:
-------------------------------------
Summary: Boot errors should hide the failure description if the failing operation address is not accessible (was: BOot errors should hide the failure description if the failing operation address is not accessible)
> Boot errors should hide the failure description if the failing operation address is not accessible
> --------------------------------------------------------------------------------------------------
>
> Key: WFCORE-769
> URL: https://issues.jboss.org/browse/WFCORE-769
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.Alpha4
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> The boot error collector reports whatever failure-description it was passed. Those can include pretty random info, and there's no good way to know what,so it could leak some sensitive information.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFCORE-765) Shutdown error in domain mode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-765?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-765:
------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/818, https://github.com/wildfly/wildfly-core/pull/819
> Shutdown error in domain mode
> -----------------------------
>
> Key: WFCORE-765
> URL: https://issues.jboss.org/browse/WFCORE-765
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.CR6, 2.0.0.Alpha4
> Environment: Ubuntu 14.04 LTS, Oracle JDK 1.8.0_45
> Reporter: Harald Wellmann
> Assignee: Brian Stansberry
> Fix For: 1.0.0.CR7, 2.0.0.Alpha5
>
>
> h3. Scenario
> * Download and unpack wildfly-dist-9.0.0.CR2.zip.
> * Run bin/domain.sh and wait for servers to start.
> * Hit Ctrl-C.
> h3. Problem
> The following error message appears for each configured server:
> {noformat}
> [Server:server-one] 13:10:34,966 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 30) WFLYCTL0190: Step handler org.jboss.as.server.operations.ServerDomainProcessShutdownHandler$1@25f7734b for operation {"operation" => "shutdown","address" => [],"operation-id" => -1,"timeout" => -1} at address [] failed handling operation rollback -- org.jboss.msc.service.ServiceNotFoundException: Service service jboss.server.graceful-shutdown-service not found: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.server.graceful-shutdown-service not found
> [Server:server-one] at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:669)
> [Server:server-one] at org.jboss.as.controller.OperationContextImpl$OperationContextServiceRegistry.getRequiredService(OperationContextImpl.java:2013)
> [Server:server-one] at org.jboss.as.server.operations.ServerDomainProcessShutdownHandler$1$1.handleResult(ServerDomainProcessShutdownHandler.java:102)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1401)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1381)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1332)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1292)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1180)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:937)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:885)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
> [Server:server-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:218)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:234)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:174)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:137)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:133)
> [Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
> [Server:server-one] at javax.security.auth.Subject.doAs(Subject.java:360)
> [Server:server-one] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:149)
> [Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:149)
> [Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298)
> [Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:server-one] at java.lang.Thread.run(Thread.java:745)
> [Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> Tried on two different machines, both with Java 7 and Java 8. Also occurs with 9.0.0.CR1. Does not occur with 8.2.0.Final.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4799) cancelled ejb timers persist in data/timer-service-data
by John Whitley (JIRA)
[ https://issues.jboss.org/browse/WFLY-4799?page=com.atlassian.jira.plugin.... ]
John Whitley updated WFLY-4799:
-------------------------------
Attachment: timertest.tgz
Sorry, obvious once you know how. Tell me if you need more
> cancelled ejb timers persist in data/timer-service-data
> -------------------------------------------------------
>
> Key: WFLY-4799
> URL: https://issues.jboss.org/browse/WFLY-4799
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.CR2
> Environment: linux 4.0.4-303.fc22.x86_64, java jdk1.8.0_45 and wildfly-9.0.0.CR2
> Reporter: John Whitley
> Labels: jboss
> Attachments: timertest.tgz
>
>
> I have a Singleton bean which creates a ejb.timer on deployment. Before doing so it cancels any existing timers previously created by the bean for completeness.
> In wildfly 8 the cancelled timers were removed from data/timer-service-data/'bean'. In wildfly 9 CR2, they stay in data/timer-service-data/'bean' and appear to be re-instated on re-deployment
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4799) cancelled ejb timers persist in data/timer-service-data
by John Whitley (JIRA)
[ https://issues.jboss.org/browse/WFLY-4799?page=com.atlassian.jira.plugin.... ]
John Whitley commented on WFLY-4799:
------------------------------------
Please forgive my ignorance but how do I attach a file? I have a Netbeans project for 'timertest' which I could attach if I knew how.
> cancelled ejb timers persist in data/timer-service-data
> -------------------------------------------------------
>
> Key: WFLY-4799
> URL: https://issues.jboss.org/browse/WFLY-4799
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.CR2
> Environment: linux 4.0.4-303.fc22.x86_64, java jdk1.8.0_45 and wildfly-9.0.0.CR2
> Reporter: John Whitley
> Labels: jboss
>
> I have a Singleton bean which creates a ejb.timer on deployment. Before doing so it cancels any existing timers previously created by the bean for completeness.
> In wildfly 8 the cancelled timers were removed from data/timer-service-data/'bean'. In wildfly 9 CR2, they stay in data/timer-service-data/'bean' and appear to be re-instated on re-deployment
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4798) Memory leak in JBoss CLI
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4798?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-4798:
----------------------------------------
Please file CLI bugs in WFCORE, as that is where the code is. We just end up moving ones filed here.
> Memory leak in JBoss CLI
> ------------------------
>
> Key: WFLY-4798
> URL: https://issues.jboss.org/browse/WFLY-4798
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 8.2.0.Final, 9.0.0.CR2, 10.0.0.Alpha3
> Reporter: Josef Cacek
> Assignee: Alexey Loubyansky
>
> The JBoss CLI contains a memory leak related to CLI Kerberos authentication.
> The {{org.jboss.as.cli.impl.CommandContextImpl}} class calls the {{initJaasConfig()}} in its constructor,
> which adds a new {{JaasConfigurationWrapper}} instance to {{javax.security.auth.login.Configuration}}.
> It's done for every new {{CommandContext}} instance, so it consumes more and more memory. There is no cleanup for the registered
> configurations.
> Moreover, the searches for appropriate
> login config take more and more time because they have to go through all the wrapped objects.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4792) Undertow deployment-level session statistics not available for distributable webapp
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-4792?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-4792:
------------------------------------
[~pferraro] Yes, thanks for the correction. I've updated the summary.
> Undertow deployment-level session statistics not available for distributable webapp
> -----------------------------------------------------------------------------------
>
> Key: WFLY-4792
> URL: https://issues.jboss.org/browse/WFLY-4792
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 9.0.0.CR2
> Reporter: Martin Kouba
> Assignee: Paul Ferraro
>
> {{org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager}} which is used by default even for non-HA configurations in WildFly 9.0.0.CR2 (e.g. {{standalone.xml}} in app server distribution) does not implement {{io.undertow.server.session.SessionManagerStatistics}} and so no stats except for {{activeSessions}} are available.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4792) Undertow deployment-level session statistics not available for distributable webapp
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-4792?page=com.atlassian.jira.plugin.... ]
Martin Kouba updated WFLY-4792:
-------------------------------
Summary: Undertow deployment-level session statistics not available for distributable webapp (was: Undertow deployment-level session statistics not available)
> Undertow deployment-level session statistics not available for distributable webapp
> -----------------------------------------------------------------------------------
>
> Key: WFLY-4792
> URL: https://issues.jboss.org/browse/WFLY-4792
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 9.0.0.CR2
> Reporter: Martin Kouba
> Assignee: Paul Ferraro
>
> {{org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager}} which is used by default even for non-HA configurations in WildFly 9.0.0.CR2 (e.g. {{standalone.xml}} in app server distribution) does not implement {{io.undertow.server.session.SessionManagerStatistics}} and so no stats except for {{activeSessions}} are available.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4779) Persisting an empty list [] gets read as a list with empty string [""] resulting in IllegalArgumentException
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4779?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-4779:
--------------------------------------
Update:
With fix for WFCORE-763 in core we will still persist an empty list, but re-read it correctly as an empty list.
> Persisting an empty list [] gets read as a list with empty string [""] resulting in IllegalArgumentException
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4779
> URL: https://issues.jboss.org/browse/WFLY-4779
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 9.0.0.CR2, 10.0.0.Alpha2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 9.0.0.Final, 10.0.0.Alpha4
>
>
> Affects at least infinispan aliases and modcluster proxies...
> (20:09:22) rhusar: pferraro: https://gist.github.com/rhusar/5eef22d7a6479f042a5d#file-gistfile1-txt-L23
> (20:09:34) rhusar: pferraro: if i write an empy list, read it back -> empty list
> (20:09:57) rhusar: pferraro: if i use the default writeAttribute, reload, read it back and i have a list of size 1 containing empty String..
> (20:23:23) rhusar: pferraro: alright, this is also "broken" in the infiinispan subsystem aliases
> (20:23:24) rhusar: pferraro: 20:22:55,775 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 40) WFLYCTL0013: Operation ("add") failed - address: ([
> (20:23:24) rhusar: ("subsystem" => "infinispan"),
> (20:23:24) rhusar: ("cache-container" => "hibernate")
> (20:23:24) rhusar: ]): java.lang.IllegalArgumentException: Empty name segment is not allowed for infinispan
> (20:23:24) rhusar: at org.jboss.msc.service.ServiceName.of(ServiceName.java:90)
> (20:23:24) rhusar: at org.jboss.msc.service.ServiceName.append(ServiceName.java:117)
> (20:23:24) rhusar: at org.wildfly.clustering.infinispan.spi.service.CacheContainerServiceName$1.getServiceName(CacheContainerServiceName.java:35)
> (20:23:24) rhusar: at org.jboss.as.clustering.infinispan.subsystem.CacheContainerBuilder.build(CacheContainerBuilder.java:79)
> (20:23:24) rhusar: at org.jboss.as.clustering.infinispan.subsystem.CacheContainerAddHandler.installRuntimeServices(CacheContainerAddHandler.java:165)
> (20:23:24) rhusar: at org.jboss.as.clustering.infinispan.subsystem.CacheContainerAddHandler.performRuntime(CacheContainerAddHandler.java:82)
> (20:23:24) rhusar: at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:309)
> (20:23:24) rhusar: at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:130)
> (20:23:24) rhusar: at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:822)
> (20:23:24) rhusar: at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:620)
> (20:23:24) rhusar: at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:373)
> (20:23:24) rhusar: at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:349)
> (20:23:24) rhusar: at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359)
> (20:23:24) rhusar: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> (20:23:24) rhusar: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> (20:23:24) rhusar: at java.lang.Thread.run(Thread.java:745)
> (20:23:24) rhusar: at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months