April 2015 - jboss-jira - Jboss List Archives

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

11 years, 1 month

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)

11 years, 1 month

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)

11 years, 1 month

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)

11 years, 1 month

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)

11 years, 1 month

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)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3652) Network connection leak

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3652?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-3652: ---------------------------------------- [~codeprince] FYI when a Jira issue is marked as 'Done' the 'Fix Version' field indicates which release contains the fix. > Network connection leak > ----------------------- > > Key: WFLY-3652 > URL: https://issues.jboss.org/browse/WFLY-3652 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: Linux 2.6.38-16-server > Java(TM) SE Runtime Environment (build 1.7.0_45-b18) > Reporter: Jan Vanhercke > Assignee: Stuart Douglas > Fix For: 9.0.0.Alpha1 > > > When using Asynchronous servlets and AsyncListeners for long polling we observe a connection leak in the undertow subsystem. > Heap dumps show a large number of org.xnio.io.NioSocketConduit, io.undertow.server.protocol.http.HttpServerConnection and related objects. > However, since the effective number of connections is far less, nearly all AsyncContext instances we find are in a complete state and lsof output returns a large number of sockets with 'can't identify protocol' entries indicating that sockets are kept open by the JVM but are in fact half closed by the network stack. > Not all connections appear to be leaking, but over time, depending on the load, the server instance fills up. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3652) Network connection leak

by Jason Spittel (JIRA)

[ https://issues.jboss.org/browse/WFLY-3652?page=com.atlassian.jira.plugin.... ] Jason Spittel commented on WFLY-3652: ------------------------------------- Where can I find the git commit for this? In the undertow repo? If in the wildfly repo, searching for 'WFLY-3652' in the logs or 3652 or 'Network connection leak' is not returning anything. > Network connection leak > ----------------------- > > Key: WFLY-3652 > URL: https://issues.jboss.org/browse/WFLY-3652 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: Linux 2.6.38-16-server > Java(TM) SE Runtime Environment (build 1.7.0_45-b18) > Reporter: Jan Vanhercke > Assignee: Stuart Douglas > Fix For: 9.0.0.Alpha1 > > > When using Asynchronous servlets and AsyncListeners for long polling we observe a connection leak in the undertow subsystem. > Heap dumps show a large number of org.xnio.io.NioSocketConduit, io.undertow.server.protocol.http.HttpServerConnection and related objects. > However, since the effective number of connections is far less, nearly all AsyncContext instances we find are in a complete state and lsof output returns a large number of sockets with 'can't identify protocol' entries indicating that sockets are kept open by the JVM but are in fact half closed by the network stack. > Not all connections appear to be leaking, but over time, depending on the load, the server instance fills up. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWEB-312) response.setBufferSize() has no effect when using the response writer

by Remy Maucherat (JIRA)

[ https://issues.jboss.org/browse/JBWEB-312?page=com.atlassian.jira.plugin.... ] Remy Maucherat commented on JBWEB-312: -------------------------------------- It is probably a great bad idea. It won't have any performance benefit, but it uses a lot more memory per connection (the buffer is never discarded, but recycled). > response.setBufferSize() has no effect when using the response writer > --------------------------------------------------------------------- > > Key: JBWEB-312 > URL: https://issues.jboss.org/browse/JBWEB-312 > Project: JBoss Web > Issue Type: Bug > Affects Versions: JBossWeb-7.5.0.GA > Reporter: Aaron Ogburn > Assignee: Aaron Ogburn > > This is the same issue as https://issues.apache.org/bugzilla/show_bug.cgi?id=55842 > When using the response writer, we end up just flushing the buffer in org.apache.catalina.connector.OutputBuffer.realWriteChars instead of trying to grow the buffer. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-761) Guided decision trees - new test for testing of unmarshalling drls containing different line endings

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-761: ------------------------------------ Summary: Guided decision trees - new test for testing of unmarshalling drls containing different line endings Key: DROOLS-761 URL: https://issues.jboss.org/browse/DROOLS-761 Project: Drools Issue Type: Enhancement Reporter: Tibor Zimányi Assignee: Michael Anstis Priority: Minor Drls can be written on different operating systems so they can contain different line endings. There is a need for test that will test unmarshalling DRLs with different line endings into GuidedDecisionTree models. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015