[
https://issues.jboss.org/browse/WFCORE-2089?page=com.atlassian.jira.plugi...
]
Brian Stansberry edited comment on WFCORE-2089 at 12/7/16 5:47 PM:
-------------------------------------------------------------------
Not really. The reason the server was aborting is because MSC was locked up because a
bunch of services were doing JMX calls and blocking. MSC being unable to stabilize
triggers a failed boot and an abort. But my guess is your JMX change will remove the
problem with MSC not stabilizing, and we'll just be left with this service not
starting. And that alone won't trigger abort.
I think it's ok for AccessIdentityAddHandler to add a Stage.VERIFY step that checks
that the IdentityService is up and calls context.setRollbackOnly() if not. That will
ensure that boot rolls back and aborts if that service isn't up.
I think the key thing though is to get that blocking future.get() out of there.
<vaguely-waving-hands>Perhaps use the IdentityService itself as the
Supplier(s).</vaguely-waving-hands> It knows if it has completed start(), and if
yes, its suppliers return the domain, if not return null. Until IdentityService completes
start, this facility is unavailable, and if it doesn't complete start the server is
going down.
was (Author: brian.stansberry):
Not really. The reason the server was aborting is because MSC was locked up because a
bunch of services were doing JMX calls and blocking. MSC being unable to stabilize
triggers a failed boot and an abort. But my guess is your JMX change will remove the
problem with MSC not stabilizing, and we'll just be left with this service not
starting. And that alone won't trigger abort.
I think it's ok for AccessIdentityAddHandler to add a Stage.VERIFY step that checks
that the IdentityService is up and calls context.setRollbackOnly() if not. That will
ensure that boot rolls back and aborts if that service isn't up.
I think the key thing though is to get that blocking future.get() out of there.
<vaguely-waving-hands>Perhaps use the IdentityService itself as the
Supplier(s).</vaguely-waving-hands> It knows if it has completed start(), and if
yes, its suppliers return the domain, if not return null. Until IdentityService completes
start, this facility is unavailable, and if it doesn't complete start the service is
going down.
Infinite wildfly boot on StartException in service start
--------------------------------------------------------
Key: WFCORE-2089
URL:
https://issues.jboss.org/browse/WFCORE-2089
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Security
Reporter: Jan Kalina
Assignee: Darran Lofthouse
Priority: Blocker
Attachments: threads-2.txt, threads.txt
Following exception (and probably similar too) will cause wildfly frozing during start.
Visible especially during integration tests (which will never ends), but reproducible
directly too (see steps).
{code:java}
15:59:37,252 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001:
Failed to start service org.wildfly.security.security-realm.ManagementRealm:
org.jboss.msc.service.StartException in service
org.wildfly.security.security-realm.ManagementRealm: WFLYELY00025: Referenced property
file is invalid: ELY01006: No realm name found in password property file
at
org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:185)
at
org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:164)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
*Update:* This problem with infinite boot will occure everytime the start() method of
some service throws StartException(). Not an Elytron problem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)