September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBFORUMS-109) BBCode support for standalone version

by Ryszard Kozmik (JIRA)

BBCode support for standalone version ------------------------------------- Key: JBFORUMS-109 URL: http://jira.jboss.com/jira/browse/JBFORUMS-109 Project: JBoss Forums Issue Type: Task Components: Forum Enhancements Reporter: Ryszard Kozmik Fix For: 1.0.0 Alpha BBCode parser is now working only in portal environment. We need make it work as a standalone too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 weeks

4
5
0 / 0

[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender

by Bela Ban (JIRA)

Optimization: make threads return immediately if NAKACK has another active thread for the same sender ----------------------------------------------------------------------------------------------------- Key: JGRP-457 URL: http://jira.jboss.com/jira/browse/JGRP-457 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.5 In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up. If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock. The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 months

2
3
0 / 0

[JBoss JIRA] (JBRULES-3445) DSL expander expands lines in /* */comment block

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3445: ------------------------------------ Summary: DSL expander expands lines in /* */comment block Key: JBRULES-3445 URL: https://issues.jboss.org/browse/JBRULES-3445 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco When you comment some code in dslr file, the expander still tries to expand it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

7 months, 3 weeks

3
10
0 / 0

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

9 years, 2 months

1
0
0 / 0

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

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-522) Add callbacks for persisting and restoring a SecurityIdentity

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-522?page=com.atlassian.jira.plugin.sy... ] Pedro Igor commented on ELY-522: -------------------------------- [~darranl], can we close this issue in favor of https://issues.jboss.org/browse/ELY-624 ? > Add callbacks for persisting and restoring a SecurityIdentity > ------------------------------------------------------------- > > Key: ELY-522 > URL: https://issues.jboss.org/browse/ELY-522 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-522) Add callbacks for persisting and restoring a SecurityIdentity

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-522?page=com.atlassian.jira.plugin.sy... ] Pedro Igor edited comment on ELY-522 at 9/30/16 4:53 PM: --------------------------------------------------------- [~darranl], can we close this issue now that https://issues.jboss.org/browse/ELY-624 is merged ? was (Author: pcraveiro): [~darranl], can we close this issue in favor of https://issues.jboss.org/browse/ELY-624 ? > Add callbacks for persisting and restoring a SecurityIdentity > ------------------------------------------------------------- > > Key: ELY-522 > URL: https://issues.jboss.org/browse/ELY-522 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-628) Allow JWT-based token realms to operate in parse-only mode

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-628?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-628: --------------------------- Fix Version/s: 1.1.0.Beta10 (was: 1.1.0.Beta11) > Allow JWT-based token realms to operate in parse-only mode > ---------------------------------------------------------- > > Key: ELY-628 > URL: https://issues.jboss.org/browse/ELY-628 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Affects Versions: 1.1.0.Beta8 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

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

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-650) Improvements to Elytron Web and Undertow Testsuite

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-650?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-650: --------------------------- Summary: Improvements to Elytron Web and Undertow Testsuite (was: Improvements to elytron-web testsuite) > Improvements to Elytron Web and Undertow Testsuite > -------------------------------------------------- > > Key: ELY-650 > URL: https://issues.jboss.org/browse/ELY-650 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Affects Versions: 1.1.0.Beta10 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2016