[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 days, 7 hours
[JBoss JIRA] (LOGMGR-95) Log4j Logger.getParent() inconsistent
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-95?page=com.atlassian.jira.plugin.... ]
James Perkins updated LOGMGR-95:
--------------------------------
Fix Version/s: (was: 1.1.2.CR1)
> Log4j Logger.getParent() inconsistent
> -------------------------------------
>
> Key: LOGMGR-95
> URL: https://issues.jboss.org/browse/LOGMGR-95
> Project: JBoss Log Manager
> Issue Type: Bug
> Reporter: James Livingston
> Assignee: James Perkins
>
> Log4j Loggers have a getParent() method, whose return value is set up by JBossLogManagerFacade.updateParents(). The method locates the closest parent node which has an existing Log4J logger created *at the time*. This results in the parent being different depending on the order Log4j loggers are used in.
> Consider:
> Logger.getLogger("a");
> Logger.getLogger("a.b.c");
> Logger.getLogger("a.b");
> When the second line causes updateParents() to be called, LoggerNode.getOrCreate() has already created the intermediate "a.b" node. That does not yet have a Log4j Logger created, so the Logger for "a" is returned. Original log4j would have returned "a.b" due to it using the parent structure in the implementation.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years
[JBoss JIRA] (WFLY-3260) Fix WSTestCase
by Matus Abaffy (JIRA)
[ https://issues.jboss.org/browse/WFLY-3260?page=com.atlassian.jira.plugin.... ]
Matus Abaffy resolved WFLY-3260.
--------------------------------
Fix Version/s: 9.0.0.Alpha1
Resolution: Done
> Fix WSTestCase
> --------------
>
> Key: WFLY-3260
> URL: https://issues.jboss.org/browse/WFLY-3260
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Web Services
> Affects Versions: 8.1.0.CR1
> Reporter: Matus Abaffy
> Assignee: Matus Abaffy
> Fix For: 9.0.0.Alpha1
>
>
> Package org.jboss.as.test.smoke.webservices contains SimpleStatelessSessionBean with several @WebServiceRef injection points.
> SimpleStatelessSessionBean is injected into SimpleServlet. However, SimpleServlet is never initialized and an instance of SimpleStatelessSessionBean is never created. Therefore, no @WebServiceRef injection is tested here.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years
[JBoss JIRA] (WFCORE-29) IllegalStateException when patching MBeans are queried during shutdown
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-29?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFCORE-29:
-----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/51 (was: https://github.com/wildfly/wildfly/pull/6426)
> IllegalStateException when patching MBeans are queried during shutdown
> ----------------------------------------------------------------------
>
> Key: WFCORE-29
> URL: https://issues.jboss.org/browse/WFCORE-29
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Patching
> Reporter: James Livingston
> Assignee: Emanuel Muckenhuber
> Attachments: shutdownmbeanquery.jar
>
>
> If the MBeans for the patching subsystem are queried during server shutdown, it can result in an IllegalStateException. InstallationManagerService has already had stop() called on it, so the value is null.
> This can be reproduced by the attached EJB, which does a MBeanServer.queryMBeans(null, null); from the @PreDestroy method. It's in a loop to ensure it runs after the installation manager gets de-initialised.
> java.lang.IllegalStateException
> at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:87) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:28) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.children(PatchResource.java:139) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.hasChildren(PatchResource.java:134) [wildfly-patching-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.registry.AbstractModelResource.hasChildren(AbstractModelResource.java:81) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.hasChildren(AbstractModelResource.java:279) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:57) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.queryMBeans(ModelControllerMBeanHelper.java:125) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.queryMBeans(ModelControllerMBeanServerPlugin.java:159) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.queryMBeans(PluggableMBeanServerImpl.java:816) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at example.ShutdownMBeanQuery.destroy(ShutdownMBeanQuery.java:23)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-1067 at 9/30/14 4:09 PM:
--------------------------------------------------------------------
This integration exercise is going to be tricky. The AS security infrastructure is completely based on a very narrow set of mechanisms (callbacks, SSLContexts) and does not, as far as I can tell, give direct access to the initial configuration information, such as the underlying password files or keystores. JGroups AUTH and ENCRYPT protocols, on the other hand, do not make use of callbacks or pre-processed SSLContexts and assume access to the initial configuration information, like the password files and keystores.
This could be helped by having some means to access the original configuration information for each mechanism. I suppose it could be looked up from the model in the addressable resource for the realm, given the realm and the mechanism. Whether or not this is legitimate or the best way of providing this information or will cause complications is another matter.
The SASL JGroups protocol layer does already provide integration with security-realms for authentication. Tristan has cited this as the main reason for implementing the layer. But this does not help with ENCRYPT nor the non-standard AUTH mechanisms.
was (Author: rachmato):
This integration exercise is going to be tricky. The AS security infrastructure is completely based on a very narrow set of mechanisms (callbacks, SSLContexts) and does not, as far as I can tell, give direct access to the initial configuration information, such as the underlying password files or keystores. JGroups AUTH and ENCRYPT protocols, on the other hand, do not make use of callbacks or pre-processed SSLContexts and assume access to the initial configuration information, like the password files and keystores.
This could be helped by having some means to access the original configuration information for each mechanism. I suppose it could be looked up from the model in the addressable resource for the realm, given the realm and the mechanism. Whether or not this is legitimate or the best way of providing this information or will cause complications is another matter.
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.jboss.org/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years
[JBoss JIRA] (WFLY-3260) Fix WSTestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3260?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3260:
----------------------------------------
Isn't this done?
> Fix WSTestCase
> --------------
>
> Key: WFLY-3260
> URL: https://issues.jboss.org/browse/WFLY-3260
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Web Services
> Affects Versions: 8.1.0.CR1
> Reporter: Matus Abaffy
> Assignee: Matus Abaffy
>
> Package org.jboss.as.test.smoke.webservices contains SimpleStatelessSessionBean with several @WebServiceRef injection points.
> SimpleStatelessSessionBean is injected into SimpleServlet. However, SimpleServlet is never initialized and an instance of SimpleStatelessSessionBean is never created. Therefore, no @WebServiceRef injection is tested here.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years
[JBoss JIRA] (WFLY-3918) Cannot disable ConsoleRedirectService
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3918?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-3918:
---------------------------------
Assignee: Tomaz Cerar (was: Stuart Douglas)
> Cannot disable ConsoleRedirectService
> -------------------------------------
>
> Key: WFLY-3918
> URL: https://issues.jboss.org/browse/WFLY-3918
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Reporter: Graham Johnson
> Assignee: Tomaz Cerar
>
> Wildfly Undertow (via org.wildfly.extension.undertow.HostAdd and org.wildfly.extension.undertow.ConsoleRedirectService) redirects all /console/... URL requests (on port 8080/8443) to /console on port 9990.
> This prevents developing or porting applications that themselves need to serve /console/... URLs.
> There needs to be a way to disable (in the undertow subsystem configuration) the adding of ConsoleRedirectService by HostAdd.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years