[JBoss JIRA] (WFLY-9190) Comment out unused Logger methods
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-9190:
--------------------------------------
Summary: Comment out unused Logger methods
Key: WFLY-9190
URL: https://issues.jboss.org/browse/WFLY-9190
Project: WildFly
Issue Type: Task
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The various XXXLogger/XXXMessages classes over the years have accumulated numerous currently unused methods. That's wasted code, both in the interfaces and even more so in the generated implementations. That code wastes memory and loading it increases boot time.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9191) Comment out unused Logger methods
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-9191:
--------------------------------------
Summary: Comment out unused Logger methods
Key: WFLY-9191
URL: https://issues.jboss.org/browse/WFLY-9191
Project: WildFly
Issue Type: Task
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The various XXXLogger/XXXMessages classes over the years have accumulated numerous currently unused methods. That's wasted code, both in the interfaces and even more so in the generated implementations. That code wastes memory and loading it increases boot time.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code
by István Tóth (JIRA)
[ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.... ]
István Tóth commented on WFLY-8431:
-----------------------------------
Is there anything I can do to get these fixes in WF 11 final ?
> Race conditions in JASPIC registration code
> -------------------------------------------
>
> Key: WFLY-8431
> URL: https://issues.jboss.org/browse/WFLY-8431
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Environment: Centos 7 x86_64, with the included Java 8 environment
> Reporter: István Tóth
> Assignee: Darran Lofthouse
> Attachments: GetFactoryTestCase.java
>
>
> javax.security.auth.message.config.AuthConfigFactory and
> org.jboss.security.auth.message.config.JBossAuthConfigFactory
> have race conditions.
> 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic.
> I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized)
> 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe.
> Nearly all methods of this class manipulate these, without any synchronization.
> In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty.
> The methods that modify the maps should also be made synchronized, or rewritten to use the
> atomic ConcurrentHashMaps operations.
> A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (LOGTOOL-130) Remove the usage of static strings from the generated source
by James Perkins (JIRA)
James Perkins created LOGTOOL-130:
-------------------------------------
Summary: Remove the usage of static strings from the generated source
Key: LOGTOOL-130
URL: https://issues.jboss.org/browse/LOGTOOL-130
Project: Log Tool
Issue Type: Enhancement
Reporter: James Perkins
Assignee: James Perkins
Fix For: 2.1.0.Beta2
Currently there is a private static string constant created for each message. This string is just returned in the `methodName$str()` method. Instead of creating the string constant just have the generated method return the message string. This reduces the size of the metaspace required for the class.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3103) Embedded server doesn't close open file handles
by Jan Blizňák (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3103?page=com.atlassian.jira.plugi... ]
Jan Blizňák commented on WFCORE-3103:
-------------------------------------
[~luck3y], the reproducer isn't trying to find open handles, it just tries to delete files, exactly as the manual steps say:
* start a CLI wrapper
* start embed-server from given server path
* stop embed-server
* terminate CLI wrapper
* try to delete given server path, ie. the files that were opened in order to start embed-server and that should no longer be opened after embed-server was stopped.
So test should pass when all these steps succeeded, ie. after this jira is fixed. But the last step currently fails everytime on all Win OSes I tried because there are open files from modules dir (I don't have Win 10, but I suppose Win Server 2016 is equivalent in this case). I was using EAP 7.1.0.ER3 and also today's Wildfly 11.0.0.Beta1 (wildfly-core 3.0.0.Beta30).
In case you want verbose output of the testcase, you need to download handle.exe tool from https://docs.microsoft.com/en-us/sysinternals/downloads/handle and execute the reproducer like this (the handle.exe serves only as additional info here to list locked files):
{{mvn clean test "-Dwildfly.home=C:\tmp\wildfly-11.0.0.Beta1" "-Dhandle.exe=C:\tmp\handle.exe" -Dtest=ModulesFileLockingTestCase}}
> Embedded server doesn't close open file handles
> -----------------------------------------------
>
> Key: WFCORE-3103
> URL: https://issues.jboss.org/browse/WFCORE-3103
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Modules
> Reporter: Jan Blizňák
> Assignee: Ken Wills
>
> When embedded server is started programatically (eg. via CLI wrapper) with specified jboss home, JARs from that path are opened via classloader. But these open handles are never released even after embedded server is stopped.
> This causes problem in situation eg. when you want to delete that jboss home. This is exactly one of the scenarios used in EAP installer, you are not allowed to delete open files on Windows - see JBEAP-1404.
> I created a simple project that reproduce the issue with arbitrary EAP/WF distribution https://github.com/jbliznak/embedded-server-filelocking
> Run it with:
> mvn clean test "-Dwildfly.home=C:\dev\jboss-eap-7.1" "-Denforcer.skip" -Dtest=ModulesFileLockingTestCase
> Manual steps to reproduce in Java code:
> * start a CLI wrapper
> * start embed-server from given server path
> * stop embed-server
> * terminate CLI wrapper
> * try to delete given server path
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months