April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by John Mezzetta (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] John Mezzetta commented on LOGMGR-120: -------------------------------------- Hi, Thiago is away for 6 weeks and I am currently doing characteristics testing on the proposed solution. >From a performance perspective, the implementation does not satisfy requirements. Essentially, every time a logger object is accessed (even if forceLogging turns out to be false), 5 instances of the jboss Logger class are instantiated (assuming that the category being logged has a name that is 5 deep - i.e. 1.2.3.4.5). This happens because of this snippet of code in Logger.java: private boolean forceLogging() { if (!FORCING_LOG_CHECKER.isForcingLogFeatureEnabled()) { return false; } final CheckForceLogCallback result = loggerNode.getCheckForceLogCallback(); if (result != null) { return result.isForcingLog(); } final Logger parent = getParent(); return parent != null && parent.forceLogging(); } The call to getParent is a problem. It causes the instantiation of a new logger object. And it is recursive to the root, so multiple objects are created per call. In my test app, if traffic is light, the problem is not noticed. but under heavy logger use, it seems that all of these objects cannot be GCed fast enough because they have a finalize method. Regardless, the implementation is far too inefficient. We cannot have so many method invocations and object instantiations per logger call. Basically, the requirement was to have an extra 2 or 3 high level instructions per logger call to determine if forcelogging is on. And this was on both sides, not just the jboss side. The current implementation is in the 50-100 range on the jboss side alone. The proposal to fix this would be: 1. create a static method in a class (LogManager.java?) for the "forceLogging() method. 2. when the LogManager initiaizes, it needs to perform an SPI lookup for implementors of the org.jboss.logmanager.CheckForceLogCallback interface. We would provide that implementor (and deal with the obvious classpath issues by modifying the jboss loggin module.xm). If there are no implementors found in the SPI lookup, the forceLogging() method would return false. This would effectively mean the feature is disabled. If an implementation is found, the forceLogging() method is passed though to the implementation. 3. this means that the forceLogging method above would be replaced by a call to the static method in LogManager. And when the feature is disabled, LogManager would return a local Boolean. While a productified version of this feature would probably be different, this would be the most concise and efficient implementation that would satisfy our requirements. What do you think? Regards, John > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > Attachments: force_logging.patch > > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-634) Intermittent failures in SSLMasterSlaveOneWayTestCase

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-634: --------------------------------------- Summary: Intermittent failures in SSLMasterSlaveOneWayTestCase Key: WFCORE-634 URL: https://issues.jboss.org/browse/WFCORE-634 Project: WildFly Core Issue Type: Bug Components: Domain Management, Test Suite Reporter: Brian Stansberry Assignee: Ondrej Kotek This test is failing intermittently. I'm going to @Ignore it. See http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WildFlyCore_... Example failure: {code} java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:189) at java.net.SocketInputStream.read(SocketInputStream.java:121) at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:139) at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:155) at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:284) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261) at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165) at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) at org.jboss.as.test.integration.domain.AbstractSSLMasterSlaveTestCase.executeOverHttp(AbstractSSLMasterSlaveTestCase.java:169) at org.jboss.as.test.integration.domain.AbstractSSLMasterSlaveTestCase.isHostStateRunning(AbstractSSLMasterSlaveTestCase.java:144) at org.jboss.as.test.integration.domain.AbstractSSLMasterSlaveTestCase.checkHostStatusOnMaster(AbstractSSLMasterSlaveTestCase.java:112) at org.jboss.as.test.integration.domain.AbstractSSLMasterSlaveTestCase.setOriginMasterManagementNativeInterfaceAndCheck(AbstractSSLMasterSlaveTestCase.java:96) at org.jboss.as.test.integration.domain.SSLMasterSlaveOneWayTestCase.setOriginMasterManagementNativeInterface(SSLMasterSlaveOneWayTestCase.java:100) {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4494) Delete Unused WebUtil Class

by Philippe Marschall (JIRA)

Philippe Marschall created WFLY-4494: ---------------------------------------- Summary: Delete Unused WebUtil Class Key: WFLY-4494 URL: https://issues.jboss.org/browse/WFLY-4494 Project: WildFly Issue Type: Patch Components: Web (Undertow) Reporter: Philippe Marschall Assignee: Stuart Douglas The WebUtil class in the security package of the undertow subsystem is unused. I found the class because it invokes #toString on an array instead of calling Arrays#toString. If it was still used this would have to be fixed. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2643) Pass the jboss.server.log.dir parameter to the global system properties

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-2643?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-2643: -------------------------------- Summary: Pass the jboss.server.log.dir parameter to the global system properties (was: JBOSS_LOG_DIR is checked but not used to set jboss.server.log.dir) > Pass the jboss.server.log.dir parameter to the global system properties > ----------------------------------------------------------------------- > > Key: WFLY-2643 > URL: https://issues.jboss.org/browse/WFLY-2643 > Project: WildFly > Issue Type: Enhancement > Components: Logging, Server > Affects Versions: JBoss AS7 7.1.1.Final, 8.0.0.Beta1 > Environment: All > Reporter: Stian Lund > Priority: Optional > Labels: jbossas, logging, wildfly > > In standalone/domain start scripts (standalone.sh/bat) the value of environment variable JBOSS_LOG_DIR is checked for: > {code} > # determine the default log dir, if not set > if [ "x$JBOSS_LOG_DIR" = "x" ]; then > JBOSS_LOG_DIR="$JBOSS_BASE_DIR/log" > fi > {code} > However, this is not actually used to set the value of Java property jboss.server.log.dir. > {code} > -Djboss.home.dir="$JBOSS_HOME" > -Djboss.server.base.dir="$JBOSS_BASE_DIR" > "$SERVER_OPTS" > {code} > (It should be set at the same place) > This leads Jboss/Wildfly/EAP to assume the default value of $JBOSS_BASE_DIR/log. > This is a problem for those who want to override the location of the server.log files. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-480) Create more/better testing for custom logging handlers

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-480?page=com.atlassian.jira.plugin... ] James Perkins closed WFCORE-480. -------------------------------- Resolution: Out of Date > Create more/better testing for custom logging handlers > ------------------------------------------------------ > > Key: WFCORE-480 > URL: https://issues.jboss.org/browse/WFCORE-480 > Project: WildFly Core > Issue Type: Task > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Custom handlers cannot be test in normal subsystem tests as they require a JBoss Modules class loader. A way to either launch surfire with JBoss Modules looked at or more and better ARQ tests need to be written. There have been several issues specifically around log4j appenders as custom handlers. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4493) UrlScanner Should Close ZipFiles

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/WFLY-4493?page=com.atlassian.jira.plugin.... ] Philippe Marschall updated WFLY-4493: ------------------------------------- Description: The UrlScanner class creates ZipFile instances without invoking #close on them. This is not as bad as it sounds because ZipFile does have a finalizer but it's still suboptimal. (was: The UrlScanner class creates ZipFile instances without invoking #close on them. This is not as bad as it sounds because ZipFile does have a finalizer but still suboptimal.) > UrlScanner Should Close ZipFiles > -------------------------------- > > Key: WFLY-4493 > URL: https://issues.jboss.org/browse/WFLY-4493 > Project: WildFly > Issue Type: Patch > Components: CDI / Weld > Reporter: Philippe Marschall > Assignee: Stuart Douglas > > The UrlScanner class creates ZipFile instances without invoking #close on them. This is not as bad as it sounds because ZipFile does have a finalizer but it's still suboptimal. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4493) UrlScanner Should Close ZipFiles

by Philippe Marschall (JIRA)

Philippe Marschall created WFLY-4493: ---------------------------------------- Summary: UrlScanner Should Close ZipFiles Key: WFLY-4493 URL: https://issues.jboss.org/browse/WFLY-4493 Project: WildFly Issue Type: Patch Components: CDI / Weld Reporter: Philippe Marschall Assignee: Stuart Douglas The UrlScanner class creates ZipFile instances without invoking #close on them. This is not as bad as it sounds because ZipFile does have a finalizer but still suboptimal. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-632) Subsystem deployment undeployed at startup

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-632?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-632: ------------------------------------ Fix Version/s: 1.0.0.Beta4 (was: 1.0.0.CR1) > Subsystem deployment undeployed at startup > ------------------------------------------ > > Key: WFCORE-632 > URL: https://issues.jboss.org/browse/WFCORE-632 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Beta3, 1.0.0.Beta4 > Reporter: Stan Silvert > Assignee: Brian Stansberry > Labels: affects_elytron > Fix For: 1.0.0.Beta4 > > > {noformat} > @BrianStansberry The "mixed approach" doesn't seem to work any more. https://developer.jboss.org/wiki/ExtendingAS7 > @BrianStansberry I'm using this to deploy keycloak WAR from the subsystem. > @BrianStansberry As soon as the server is started, something is calling stopService() on the Keycloak WAR. > Tomaz Cerar > 1:15 PM > @StanSilvert are you still working on AS7? https://docs.jboss.org/author/display/WFLY8/Extending+WildFly+8 > Stan Silvert > 1:16 PM > @ctomc No. this is WildFly 9. It still works on WildFly 8. > Tomaz Cerar > 1:16 PM > ah the war deployment, that could be regression > Brian Stansberry > 1:17 PM > @ctomc how so? > Stan Silvert > 1:17 PM > FYI. I did a Thread.dumpStack() and got this: > 13:11:35,173 ERROR [stderr] (MSC service thread 1-3) java.lang.Exception: Stack trace > 13:11:35,173 ERROR [stderr] (MSC service thread 1-3) at java.lang.Thread.dumpStack(Thread.java:1329) > 13:11:35,174 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.Host.unregisterDeployment(Host.java:168) > 13:11:35,176 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java: > 113) > 13:11:35,179 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100) > 13:11:35,181 ERROR [stderr] (MSC service thread 1-3) at org.jboss.msc.service.Serv > iceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > 13:11:35,184 ERROR [stderr] (MSC service thread 1-3) at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > 13:11:35,186 ERROR [stderr] (MSC service thread 1-3) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > 13:11:35,188 ERROR [stderr] (MSC service thread 1-3) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > 13:11:35,190 ERROR [stderr] (MSC service thread 1-3) at java.lang.Thread.run(Thread.java:745) > Hide full text > Tomaz Cerar > 1:18 PM > @BrianStansberry just reffering that war deployment from subsystem should still work > 1:19 PM > Jason Greene joined the room. > Tomaz Cerar > 1:19 PM > @StanSilvert what happens? as that thread dump makes no sense > Stan Silvert > 1:21 PM > http://pastebin.com/xQ2DNzEe > The WAR is simply undeployed as soon as WildFly finishes startup. > Brian Stansberry > 1:22 PM > @StanSilvert can you give me a link to your code that's doing the deploy stuff? > Stan Silvert > 1:22 PM > just a sec > Stan Silvert > 1:24 PM > https://github.com/keycloak/keycloak/tree/master/integration > The code that creates the operation is https://github.com/keycloak/keycloak/blob/master/integration > AuthServerUtil ^^^ > click on the second link > 1:27 PM > Darran Lofthouse left the room. > Brian Stansberry > 1:27 PM > @StanSilvert are you doing overlay stuff? I see some code there re: overlays > Stan Silvert > 1:28 PM > Yes, but not in this instance. > Brian Stansberry > 1:28 PM > ok. I'm asking just because that would add more complexity, better scope for some service dependency going missing, triggering stop > Stan Silvert > 1:29 PM > For this simple case there are no overlays. > Brian Stansberry > 1:29 PM > @StanSilvert interesting, your log looks like it's a true undeploy op, not just a service stop > Tomaz Cerar > 1:30 PM > @BrianStansberry should we use 6.x.0 or 6.x.latest for tranformers testing? > Tomaz Cerar goes get some diner > Stan Silvert > 1:30 PM > @BrianStansberry If that's the case then maybe some condition is triggering my own undeploy operation. > @BrianStansberry I'll look into that and see what I find. > Brian Stansberry > 1:31 PM > @ctomc 6.x.0 is ok by me; chasing CPs is too much hassle > @StanSilvert note this: > 13:11:35,294 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0009: Undeployed "main-auth-server.war" (runtime-name: "main-auth-server.war") > the thread -- DeploymentScanner-threads - 1 > looks like your deployment is exposed to the scanner? > oh, here's a guess! > the scanner sees "persistent" => false and treats it as under scanner control > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4492) Remove Unused Variables in Connector Subsystem

by Philippe Marschall (JIRA)

Philippe Marschall created WFLY-4492: ---------------------------------------- Summary: Remove Unused Variables in Connector Subsystem Key: WFLY-4492 URL: https://issues.jboss.org/browse/WFLY-4492 Project: WildFly Issue Type: Patch Components: JCA Reporter: Philippe Marschall Assignee: Jesper Pedersen There are various unused variables in the connector subsystem that can be deleted. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-65) Filesystem deployment scanner deployment failure removes other scanners ' deployments

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-65?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFCORE-65: ----------------------------------- Fix Version/s: 1.0.0.Beta4 > Filesystem deployment scanner deployment failure removes other scanners ' deployments > ------------------------------------------------------------------------------------- > > Key: WFCORE-65 > URL: https://issues.jboss.org/browse/WFCORE-65 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha5 > Reporter: ehsavoie Hugonnet > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta4 > > > There is no way to associate a deployment to a specific scanner thus if one deployment fails for a scanner during startup all deployments not persistent will be removed -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 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 April 2015