[JBoss JIRA] (WFCORE-1845) Logging subsystem scans the CWD on server boot
by Brent Douglas (JIRA)
Brent Douglas created WFCORE-1845:
-------------------------------------
Summary: Logging subsystem scans the CWD on server boot
Key: WFCORE-1845
URL: https://issues.jboss.org/browse/WFCORE-1845
Project: WildFly Core
Issue Type: Feature Request
Components: Logging
Affects Versions: 2.0.10.Final
Environment: OSX El Capitan, Oracle JDK 1.8.0_92 && 101, swarm 2016.8.1, WF 10.0.0.Final, WF-CORE 2.0.10.Final
Reporter: Brent Douglas
Assignee: James Perkins
When booting the server from a directory where the subtree is large the server hangs for a long time. JStack shows that the logging subsystem is scanning the CWD.
Booting the server from the root dir of a maven parent project containing 2 subprojects, a swarm project and a small NPM subproject added 33s to the server boot time compared to stepping into the swarm project and booting it.
Stacktrace while the server is booting:
{noformat}
Thread 25859: (state = IN_NATIVE)
- sun.nio.fs.UnixNativeDispatcher.lstat0(long, sun.nio.fs.UnixFileAttributes) @bci=0 (Compiled frame; information may be imprecise)
- sun.nio.fs.UnixNativeDispatcher.lstat(sun.nio.fs.UnixPath, sun.nio.fs.UnixFileAttributes) @bci=10, line=300 (Compiled frame)
- sun.nio.fs.UnixFileAttributes.get(sun.nio.fs.UnixPath, boolean) @bci=22, line=72 (Compiled frame)
- sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes() @bci=15, line=52 (Compiled frame)
- sun.nio.fs.UnixFileSystemProvider.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=57, line=144 (Compiled frame)
- java.nio.file.Files.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=7, line=1737 (Compiled frame)
- java.nio.file.FileTreeWalker.getAttributes(java.nio.file.Path, boolean) @bci=56, line=219 (Compiled frame)
- java.nio.file.FileTreeWalker.visit(java.nio.file.Path, boolean, boolean) @bci=3, line=276 (Compiled frame)
- java.nio.file.FileTreeWalker.next() @bci=134, line=372 (Compiled frame)
- java.nio.file.Files.walkFileTree(java.nio.file.Path, java.util.Set, int, java.nio.file.FileVisitor) @bci=256, line=2706 (Compiled frame)
- java.nio.file.Files.walkFileTree(java.nio.file.Path, java.nio.file.FileVisitor) @bci=9, line=2742 (Interpreted frame)
- org.jboss.as.logging.LoggingResource.findFiles(java.lang.String, org.jboss.dmr.ModelNode, boolean) @bci=47, line=251 (Interpreted frame)
- org.jboss.as.logging.LoggingResource.getChildrenNames(java.lang.String) @bci=37, line=157 (Interpreted frame)
- org.jboss.as.logging.LoggingResource.getChildren(java.lang.String) @bci=11, line=171 (Interpreted frame)
- org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(java.lang.String) @bci=5, line=362 (Interpreted frame)
- org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=99, line=289 (Interpreted frame)
- org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame)
- org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame)
- org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=189, line=291 (Interpreted frame)
- org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame)
- org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame)
- org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource) @bci=2, line=250 (Interpreted frame)
- org.jboss.as.controller.ModelControllerImpl.writeModel(org.jboss.as.controller.ModelControllerImpl$ManagementModelImpl, java.util.Set) @bci=19, line=769 (Interpreted frame)
- org.jboss.as.controller.OperationContextImpl.createPersistenceResource() @bci=17, line=519 (Interpreted frame)
- org.jboss.as.controller.AbstractOperationContext.executeDoneStage(org.jboss.dmr.ModelNode) @bci=22, line=708 (Interpreted frame)
- org.jboss.as.controller.AbstractOperationContext.processStages() @bci=277, line=680 (Interpreted frame)
- org.jboss.as.controller.AbstractOperationContext.executeOperation() @bci=27, line=370 (Interpreted frame)
- org.jboss.as.controller.OperationContextImpl.executeOperation() @bci=20, line=1344 (Interpreted frame)
- org.jboss.as.controller.ModelControllerImpl.boot(java.util.List, org.jboss.as.controller.client.OperationMessageHandler, org.jboss.as.controller.ModelController$OperationTransactionControl, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider, boolean, boolean) @bci=410, line=485 (Interpreted frame)
- org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider) @bci=16, line=387 (Interpreted frame)
- org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean) @bci=7, line=349 (Interpreted frame)
- org.jboss.as.server.ServerService.boot(java.util.List, boolean) @bci=22, line=392 (Interpreted frame)
- org.jboss.as.server.ServerService.boot(org.jboss.as.controller.BootContext) @bci=907, line=365 (Interpreted frame)
- org.jboss.as.controller.AbstractControllerService$1.run() @bci=12, line=299 (Interpreted frame)
- java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFCORE-1844) RemoteProxyController can block indefinitely trying to cancel a timed out operation
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1844:
----------------------------------------
Summary: RemoteProxyController can block indefinitely trying to cancel a timed out operation
Key: WFCORE-1844
URL: https://issues.jboss.org/browse/WFCORE-1844
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Trying to execute management requests against a managed domain server that is unresponsive due to OOME results in threads on the HC in stuck permanently in a state like this:
{code}
"Host Controller Service Threads - 48" #91 prio=5 os_prio=31 tid=0x00007fbbf0039800 nid=0x3d33 in Object.wait() [0x0000700003c42000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000007b64842d0> (a org.jboss.as.protocol.mgmt.ActiveOperationImpl)
at java.lang.Object.wait(Object.java:502)
at org.jboss.threads.AsyncFutureTask.awaitUninterruptibly(AsyncFutureTask.java:221)
- locked <0x00000007b64842d0> (a org.jboss.as.protocol.mgmt.ActiveOperationImpl)
at org.jboss.as.controller.client.impl.BasicDelegatingAsyncFuture.awaitUninterruptibly(BasicDelegatingAsyncFuture.java:57)
at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.awaitUninterruptibly(AbstractDelegatingAsyncFuture.java:35)
at org.jboss.as.controller.client.impl.BasicDelegatingAsyncFuture.cancel(BasicDelegatingAsyncFuture.java:74)
at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.cancel(AbstractDelegatingAsyncFuture.java:35)
at org.jboss.as.controller.remote.RemoteProxyController.execute(RemoteProxyController.java:173)
at org.jboss.as.controller.TransformingProxyController$Factory$TransformingProxyControllerImpl.execute(TransformingProxyController.java:203)
at org.jboss.as.controller.ProxyStepHandler.execute(ProxyStepHandler.java:170)
{code}
The RemoteProxyController code looks like this:
{code}
long timeout = blockingTimeout.getProxyBlockingTimeout(targetAddress, this);
prepared = queue.poll(timeout, TimeUnit.MILLISECONDS);
if (prepared == null) {
blockingTimeout.proxyTimeoutDetected(targetAddress);
futureResult.cancel(true);
{code}
The problem is that "cancel" call will block, uninterruptibly, until the remote process responds to the cancel message. Which it won't do, as it's all messed up from the OOME condition.
Hopefully this can be simply fixed by converting that call to asyncCancel.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (ELY-624) Add support for SSO and Clustered SSO
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-624?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor updated ELY-624:
---------------------------
Fix Version/s: 1.1.0.Beta10
(was: 1.1.0.Beta11)
> Add support for SSO and Clustered SSO
> -------------------------------------
>
> Key: ELY-624
> URL: https://issues.jboss.org/browse/ELY-624
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Reporter: Darran Lofthouse
> Assignee: Pedro Igor
> Priority: Critical
> Fix For: 1.1.0.Beta10
>
>
> This issue is to cover the APIs / SPIs and some implementation where Elytron is to be used with container managed SSO / Clustered SSO.
> By this we mean authentication mechanisms similar to HTTP Form where we want the resulting SecurityIdentity to be re-used across different HTTP context and possibly in the clustered case across different nodes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFCORE-1842) Support RBAC based on raw roles from an Identity
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1842?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-1842:
------------------------------------------
+1 we removed useRealmRoles as it was confusing in the context of the legacy security realms - now the roles are available from an Elytron SecurityIdentity making it possible to enable a default 1:1 mapping makes sense again.
> Support RBAC based on raw roles from an Identity
> -------------------------------------------------
>
> Key: WFCORE-1842
> URL: https://issues.jboss.org/browse/WFCORE-1842
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Pedro Igor
> Assignee: Darran Lofthouse
>
> Currently, RBAC requires a static mapping between standard roles and raw roles from an identity.
> We should be able to use RBAC without necessarily forcing this static mapping and just consider the raw roles from the identity.
> This issue may be related with exposing {{org.jboss.as.controller.access.management.WritableAuthorizerConfiguration#useRealmRoles}} in the management model.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months