March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4397) WildFly.8.1.0.Final's Asynchronous servlets cause connection leak

by Wind Wild (JIRA)

[ https://issues.jboss.org/browse/WFLY-4397?page=com.atlassian.jira.plugin.... ] Wind Wild updated WFLY-4397: ---------------------------- Description: Recently, I used Asynchronous servlets and AsyncListeners on my project.But when it runs on WildFly.8.1.0.Final,a problem appeared as following: 2015-01-10 10:08:40,936 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) JBAS015004: Caught exception writing deployment marker file /opt/jboss/standalone/deployments/OpenESBHttp_full_prd.war.isundeploying: java.io.FileNotFoundException: /opt/jboss/standalone/deployments/OpenESBHttp_full_prd.war.isundeploying (Too many open files) at java.io.FileOutputStream.open(Native Method) [rt.jar:1.7.0_25] at java.io.FileOutputStream.<init>(FileOutputStream.java:212) [rt.jar:1.7.0_25] at java.io.FileOutputStream.<init>(FileOutputStream.java:165) [rt.jar:1.7.0_25] at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.createMarkerFile(FileSystemDeploymentService.java:984) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.access$2800(FileSystemDeploymentService.java:83) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScannerTask.recordInProgress(FileSystemDeploymentService.java:1044) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:431) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:147) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25] at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) [rt.jar:1.7.0_25] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) [rt.jar:1.7.0_25] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_25] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] 2015-01-10 10:08:41,329 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) JBAS017535: Unregistered web context: /ServiceWeb 2015-01-10 10:08:41,481 INFO [net.sf.json.xml.XMLSerializer] (HttpServiceHandler-50543) Using default type string 2015-01-10 10:08:42,225 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-3) 2015-01-10 10:08:43,504 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment OpenESBHttp_full_prd.war (runtime-name: OpenESBHttp_full_prd.war) in 2373ms >From this server log,we can see that there is "Too open many files" problem.and on the WildFly‘s manager console,we can see that my project was undeployed.When i used command "lsof -p pid | wc -l" to find the count of open file-hander, 50000 open file,because there were a lot of "can't identify protocol" as following: java 25625 jbossuser 460u sock 0,6 0t0 62184686 can't identify protocol java 25625 jbossuser 461u sock 0,6 0t0 62170175 can't identify protocol java 25625 jbossuser 462u sock 0,6 0t0 62159509 can't identify protocol java 25625 jbossuser 463u sock 0,6 0t0 62193366 can't identify protocol java 25625 jbossuser 464u sock 0,6 0t0 62181816 can't identify protocol java 25625 jbossuser 465u sock 0,6 0t0 62159028 can't identify protocol java 25625 jbossuser 466u sock 0,6 0t0 62181150 can't identify protocol java 25625 jbossuser 467u sock 0,6 0t0 62165298 can't identify protocol java 25625 jbossuser 468u sock 0,6 0t0 62181859 can't identify protocol java 25625 jbossuser 469u sock 0,6 0t0 62155350 can't identify protocol java 25625 jbossuser 470u sock 0,6 0t0 62184687 can't identify protocol java 25625 jbossuser 471u sock 0,6 0t0 62150063 can't identify protocol java 25625 jbossuser 472u IPv4 70228479 0t0 TCP lesbprdapp16:webcache->192.168.53.177:23420 (ESTABLISHED) So i know there maybe occur connection leak on WildFly, and i made a test as follow: I use apache's jmeter to test this project,i use 50 users to request it,then use "lsof -p pid | can't identify protocol | wc -l" to find is there have “can't identify protocol”,the number is 0.But when i stop the request,there appeared lots of "can't identify protocol",the same phenomenon appeared on wildfly-9.0.0.Alpha1 and wildfly-8.2.0.Final but not appeared on tomcat.So i'm doubt that this is wildfly's bug,Is there anyony encounter this problem and tell me how to solve it. Moreover, i found a issue is like above problem: [WFLY-3652] Network connection leak - JBoss Issue Tracker but don't think they are the same probem,because it say the problem alrendy was fixed in wildfly-9.0.0.Alpha1,but above problem wasn't fixed when i test my project on wildfly-9.0.0.Alpha1. Who can help me solve this problem? thanks! was: Recently, I used a simple demo to test Asynchronous servlets and AsyncListeners on WildFly.8.1.0.Final,a problem appeared as following: When i used command "lsof -p pid | wc -l" to find the count of open file-hander, there were a lot of "can't identify protocol" as following: java 25625 jbossuser 460u sock 0,6 0t0 62184686 can't identify protocol java 25625 jbossuser 461u sock 0,6 0t0 62170175 can't identify protocol java 25625 jbossuser 462u sock 0,6 0t0 62159509 can't identify protocol java 25625 jbossuser 463u sock 0,6 0t0 62193366 can't identify protocol java 25625 jbossuser 464u sock 0,6 0t0 62181816 can't identify protocol java 25625 jbossuser 465u sock 0,6 0t0 62159028 can't identify protocol java 25625 jbossuser 466u sock 0,6 0t0 62181150 can't identify protocol java 25625 jbossuser 467u sock 0,6 0t0 62165298 can't identify protocol java 25625 jbossuser 468u sock 0,6 0t0 62181859 can't identify protocol java 25625 jbossuser 469u sock 0,6 0t0 62155350 can't identify protocol java 25625 jbossuser 470u sock 0,6 0t0 62184687 can't identify protocol java 25625 jbossuser 471u sock 0,6 0t0 62150063 can't identify protocol java 25625 jbossuser 472u IPv4 70228479 0t0 TCP lesbprdapp16:webcache->192.168.53.177:23420 (ESTABLISHED) So i know there maybe occur connection leak on WildFly, and i made a test as follow: I use apache's jmeter to test this project,i use 50 users to request it,then use "lsof -p pid | can't identify protocol | wc -l" to find is there have “can't identify protocol”,the number is 0.But when i stop the request,there appeared lots of "can't identify protocol",the same phenomenon appeared on wildfly-9.0.0.Alpha1 and wildfly-8.2.0.Final but not appeared on tomcat.So i'm doubt that this is wildfly's bug,Is there anyony encounter this problem and tell me how to solve it. Moreover, i found a issue is like above problem: [WFLY-3652] Network connection leak - JBoss Issue Tracker but don't think they are the same probem,because it say the problem alrendy was fixed in wildfly-9.0.0.Alpha1,but above problem wasn't fixed when i test my project on wildfly-9.0.0.Alpha1. Who can help me solve this problem? thanks! > WildFly.8.1.0.Final's Asynchronous servlets cause connection leak > ----------------------------------------------------------------- > > Key: WFLY-4397 > URL: https://issues.jboss.org/browse/WFLY-4397 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.Alpha1 > Environment: Java(TM) SE Runtime Environment (build 1.7.0_25) > Reporter: Wind Wild > Assignee: Stuart Douglas > > Recently, I used Asynchronous servlets and AsyncListeners on my project.But when it runs on WildFly.8.1.0.Final,a problem appeared as following: > > 2015-01-10 10:08:40,936 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) JBAS015004: Caught exception writing deployment marker file /opt/jboss/standalone/deployments/OpenESBHttp_full_prd.war.isundeploying: java.io.FileNotFoundException: /opt/jboss/standalone/deployments/OpenESBHttp_full_prd.war.isundeploying (Too many open files) > at java.io.FileOutputStream.open(Native Method) [rt.jar:1.7.0_25] > at java.io.FileOutputStream.<init>(FileOutputStream.java:212) [rt.jar:1.7.0_25] > at java.io.FileOutputStream.<init>(FileOutputStream.java:165) [rt.jar:1.7.0_25] > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.createMarkerFile(FileSystemDeploymentService.java:984) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.access$2800(FileSystemDeploymentService.java:83) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScannerTask.recordInProgress(FileSystemDeploymentService.java:1044) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:431) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:147) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25] > at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) [rt.jar:1.7.0_25] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) [rt.jar:1.7.0_25] > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_25] > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] > > 2015-01-10 10:08:41,329 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) JBAS017535: Unregistered web context: /ServiceWeb > 2015-01-10 10:08:41,481 INFO [net.sf.json.xml.XMLSerializer] (HttpServiceHandler-50543) Using default type string > 2015-01-10 10:08:42,225 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-3) > 2015-01-10 10:08:43,504 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment OpenESBHttp_full_prd.war (runtime-name: OpenESBHttp_full_prd.war) in 2373ms > > From this server log,we can see that there is "Too open many files" problem.and on the WildFly‘s manager console,we can see that my project was undeployed.When i used command "lsof -p pid | wc -l" to find the count of open file-hander, 50000 open file,because there were a lot of "can't identify protocol" as following: > java 25625 jbossuser 460u sock 0,6 0t0 62184686 can't identify protocol > java 25625 jbossuser 461u sock 0,6 0t0 62170175 can't identify protocol > java 25625 jbossuser 462u sock 0,6 0t0 62159509 can't identify protocol > java 25625 jbossuser 463u sock 0,6 0t0 62193366 can't identify protocol > java 25625 jbossuser 464u sock 0,6 0t0 62181816 can't identify protocol > java 25625 jbossuser 465u sock 0,6 0t0 62159028 can't identify protocol > java 25625 jbossuser 466u sock 0,6 0t0 62181150 can't identify protocol > java 25625 jbossuser 467u sock 0,6 0t0 62165298 can't identify protocol > java 25625 jbossuser 468u sock 0,6 0t0 62181859 can't identify protocol > java 25625 jbossuser 469u sock 0,6 0t0 62155350 can't identify protocol > java 25625 jbossuser 470u sock 0,6 0t0 62184687 can't identify protocol > java 25625 jbossuser 471u sock 0,6 0t0 62150063 can't identify protocol > java 25625 jbossuser 472u IPv4 70228479 0t0 TCP lesbprdapp16:webcache->192.168.53.177:23420 (ESTABLISHED) > > So i know there maybe occur connection leak on WildFly, and i made a test as follow: > I use apache's jmeter to test this project,i use 50 users to request it,then use "lsof -p pid | can't identify protocol | wc -l" to find is there have “can't identify protocol”,the number is 0.But when i stop the request,there appeared lots of "can't identify protocol",the same phenomenon appeared on wildfly-9.0.0.Alpha1 and wildfly-8.2.0.Final but not appeared on tomcat.So i'm doubt that this is wildfly's bug,Is there anyony encounter this problem and tell me how to solve it. > > Moreover, i found a issue is like above problem: > [WFLY-3652] Network connection leak - JBoss Issue Tracker > > but don't think they are the same probem,because it say the problem alrendy was fixed in wildfly-9.0.0.Alpha1,but above problem wasn't fixed when i test my project on wildfly-9.0.0.Alpha1. > > Who can help me solve this problem? thanks! -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4397) WildFly.8.1.0.Final's Asynchronous servlets cause connection leak

by Wind Wild (JIRA)

[ https://issues.jboss.org/browse/WFLY-4397?page=com.atlassian.jira.plugin.... ] Wind Wild updated WFLY-4397: ---------------------------- Description: Recently, I used a simple demo to test Asynchronous servlets and AsyncListeners on WildFly.8.1.0.Final,a problem appeared as following: When i used command "lsof -p pid | wc -l" to find the count of open file-hander, there were a lot of "can't identify protocol" as following: java 25625 jbossuser 460u sock 0,6 0t0 62184686 can't identify protocol java 25625 jbossuser 461u sock 0,6 0t0 62170175 can't identify protocol java 25625 jbossuser 462u sock 0,6 0t0 62159509 can't identify protocol java 25625 jbossuser 463u sock 0,6 0t0 62193366 can't identify protocol java 25625 jbossuser 464u sock 0,6 0t0 62181816 can't identify protocol java 25625 jbossuser 465u sock 0,6 0t0 62159028 can't identify protocol java 25625 jbossuser 466u sock 0,6 0t0 62181150 can't identify protocol java 25625 jbossuser 467u sock 0,6 0t0 62165298 can't identify protocol java 25625 jbossuser 468u sock 0,6 0t0 62181859 can't identify protocol java 25625 jbossuser 469u sock 0,6 0t0 62155350 can't identify protocol java 25625 jbossuser 470u sock 0,6 0t0 62184687 can't identify protocol java 25625 jbossuser 471u sock 0,6 0t0 62150063 can't identify protocol java 25625 jbossuser 472u IPv4 70228479 0t0 TCP lesbprdapp16:webcache->192.168.53.177:23420 (ESTABLISHED) So i know there maybe occur connection leak on WildFly, and i made a test as follow: I use apache's jmeter to test this project,i use 50 users to request it,then use "lsof -p pid | can't identify protocol | wc -l" to find is there have “can't identify protocol”,the number is 0.But when i stop the request,there appeared lots of "can't identify protocol",the same phenomenon appeared on wildfly-9.0.0.Alpha1 and wildfly-8.2.0.Final but not appeared on tomcat.So i'm doubt that this is wildfly's bug,Is there anyony encounter this problem and tell me how to solve it. Moreover, i found a issue is like above problem: [WFLY-3652] Network connection leak - JBoss Issue Tracker but don't think they are the same probem,because it say the problem alrendy was fixed in wildfly-9.0.0.Alpha1,but above problem wasn't fixed when i test my project on wildfly-9.0.0.Alpha1. Who can help me solve this problem? thanks! was: Recently, I used Asynchronous servlets and AsyncListeners on my project.But when it runs on WildFly.8.1.0.Final,a problem appeared as following: 2015-01-10 10:08:40,936 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) JBAS015004: Caught exception writing deployment marker file /opt/jboss/standalone/deployments/OpenESBHttp_full_prd.war.isundeploying: java.io.FileNotFoundException: /opt/jboss/standalone/deployments/OpenESBHttp_full_prd.war.isundeploying (Too many open files) at java.io.FileOutputStream.open(Native Method) [rt.jar:1.7.0_25] at java.io.FileOutputStream.<init>(FileOutputStream.java:212) [rt.jar:1.7.0_25] at java.io.FileOutputStream.<init>(FileOutputStream.java:165) [rt.jar:1.7.0_25] at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.createMarkerFile(FileSystemDeploymentService.java:984) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.access$2800(FileSystemDeploymentService.java:83) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScannerTask.recordInProgress(FileSystemDeploymentService.java:1044) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:431) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:147) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25] at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) [rt.jar:1.7.0_25] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) [rt.jar:1.7.0_25] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_25] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] 2015-01-10 10:08:41,329 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) JBAS017535: Unregistered web context: /ServiceWeb 2015-01-10 10:08:41,481 INFO [net.sf.json.xml.XMLSerializer] (HttpServiceHandler-50543) Using default type string 2015-01-10 10:08:42,225 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-3) 2015-01-10 10:08:43,504 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment OpenESBHttp_full_prd.war (runtime-name: OpenESBHttp_full_prd.war) in 2373ms >From this server log,we can see that there is "Too open many files" problem.and on the WildFly‘s manager console,we can see that my project was undeployed.When i used command "lsof -p pid | wc -l" to find the count of open file-hander, 50000 open file,because there were a lot of "can't identify protocol" as following: java 25625 jbossuser 460u sock 0,6 0t0 62184686 can't identify protocol java 25625 jbossuser 461u sock 0,6 0t0 62170175 can't identify protocol java 25625 jbossuser 462u sock 0,6 0t0 62159509 can't identify protocol java 25625 jbossuser 463u sock 0,6 0t0 62193366 can't identify protocol java 25625 jbossuser 464u sock 0,6 0t0 62181816 can't identify protocol java 25625 jbossuser 465u sock 0,6 0t0 62159028 can't identify protocol java 25625 jbossuser 466u sock 0,6 0t0 62181150 can't identify protocol java 25625 jbossuser 467u sock 0,6 0t0 62165298 can't identify protocol java 25625 jbossuser 468u sock 0,6 0t0 62181859 can't identify protocol java 25625 jbossuser 469u sock 0,6 0t0 62155350 can't identify protocol java 25625 jbossuser 470u sock 0,6 0t0 62184687 can't identify protocol java 25625 jbossuser 471u sock 0,6 0t0 62150063 can't identify protocol java 25625 jbossuser 472u IPv4 70228479 0t0 TCP lesbprdapp16:webcache->192.168.53.177:23420 (ESTABLISHED) So i know there maybe occur connection leak on WildFly, and i made a test as follow: I use apache's jmeter to test this project,i use 50 users to request it,then use "lsof -p pid | can't identify protocol | wc -l" to find is there have “can't identify protocol”,the number is 0.But when i stop the request,there appeared lots of "can't identify protocol",the same phenomenon appeared on wildfly-9.0.0.Alpha1 and wildfly-8.2.0.Final but not appeared on tomcat.So i'm doubt that this is wildfly's bug,Is there anyony encounter this problem and tell me how to solve it. Moreover, i found a issue is like above problem: [WFLY-3652] Network connection leak - JBoss Issue Tracker but don't think they are the same probem,because it say the problem alrendy was fixed in wildfly-9.0.0.Alpha1,but above problem wasn't fixed when i test my project on wildfly-9.0.0.Alpha1. Who can help me solve this problem? thanks! > WildFly.8.1.0.Final's Asynchronous servlets cause connection leak > ----------------------------------------------------------------- > > Key: WFLY-4397 > URL: https://issues.jboss.org/browse/WFLY-4397 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.Alpha1 > Environment: Java(TM) SE Runtime Environment (build 1.7.0_25) > Reporter: Wind Wild > Assignee: Stuart Douglas > > Recently, I used a simple demo to test Asynchronous servlets and AsyncListeners on WildFly.8.1.0.Final,a problem appeared as following: > When i used command "lsof -p pid | wc -l" to find the count of open file-hander, there were a lot of "can't identify protocol" as following: > java 25625 jbossuser 460u sock 0,6 0t0 62184686 can't identify protocol > java 25625 jbossuser 461u sock 0,6 0t0 62170175 can't identify protocol > java 25625 jbossuser 462u sock 0,6 0t0 62159509 can't identify protocol > java 25625 jbossuser 463u sock 0,6 0t0 62193366 can't identify protocol > java 25625 jbossuser 464u sock 0,6 0t0 62181816 can't identify protocol > java 25625 jbossuser 465u sock 0,6 0t0 62159028 can't identify protocol > java 25625 jbossuser 466u sock 0,6 0t0 62181150 can't identify protocol > java 25625 jbossuser 467u sock 0,6 0t0 62165298 can't identify protocol > java 25625 jbossuser 468u sock 0,6 0t0 62181859 can't identify protocol > java 25625 jbossuser 469u sock 0,6 0t0 62155350 can't identify protocol > java 25625 jbossuser 470u sock 0,6 0t0 62184687 can't identify protocol > java 25625 jbossuser 471u sock 0,6 0t0 62150063 can't identify protocol > java 25625 jbossuser 472u IPv4 70228479 0t0 TCP lesbprdapp16:webcache->192.168.53.177:23420 (ESTABLISHED) > > So i know there maybe occur connection leak on WildFly, and i made a test as follow: > I use apache's jmeter to test this project,i use 50 users to request it,then use "lsof -p pid | can't identify protocol | wc -l" to find is there have “can't identify protocol”,the number is 0.But when i stop the request,there appeared lots of "can't identify protocol",the same phenomenon appeared on wildfly-9.0.0.Alpha1 and wildfly-8.2.0.Final but not appeared on tomcat.So i'm doubt that this is wildfly's bug,Is there anyony encounter this problem and tell me how to solve it. > > Moreover, i found a issue is like above problem: > [WFLY-3652] Network connection leak - JBoss Issue Tracker > > but don't think they are the same probem,because it say the problem alrendy was fixed in wildfly-9.0.0.Alpha1,but above problem wasn't fixed when i test my project on wildfly-9.0.0.Alpha1. > > Who can help me solve this problem? thanks! -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4351) Support for server cipher suite preference

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4351?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-4351: ------------------------------------ Assignee: Darran Lofthouse (was: Stuart Douglas) Assigning to Darran, as I think this comes under the broader SSL unification effort. > Support for server cipher suite preference > ------------------------------------------ > > Key: WFLY-4351 > URL: https://issues.jboss.org/browse/WFLY-4351 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Reporter: Nico Schlebusch > Assignee: Darran Lofthouse > > Please expose config option in subsystem config to enable server cipher suite preference. The relevant API call is SSLParameters.setUseCipherSuitesOrder(boolean) in Java 8. > We are busy looking at the security of our web services exposed by Wildfly 8.2.0.Final when we came across these posts: > http://blog.ivanristic.com/2014/03/ssl-tls-improvements-in-java-8.html > http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSER... > App Server: WildFly 8.2.0.Final > Java: Java 8 Update 31 > OS: Linux / gentoo -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4390) restartable=false bach job can be restarted

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-4390?page=com.atlassian.jira.plugin.... ] Cheng Fang edited comment on WFLY-4390 at 3/2/15 7:48 PM: ---------------------------------------------------------- Fixed in project JBeret: https://github.com/jberet/jsr352/commit/eed55070a42bbd15240e14b638fb12ea8... Also tested with attached batch-restartable.zip test against a patched WildFly 9 snapshot. {code} 2015-02-28 08:21:37,154 INFO [com.example.batch.UnrestartableBatchTest] (default task-1) $$$ start(): jobid: 58, status: FAILED 2015-02-28 08:21:37,156 ERROR [stderr] (default task-1) javax.batch.operations.JobRestartException: JBERET000646: The job with name: unrestartable-job, execution id: 58, is configured not restartable 2015-02-28 08:21:37,156 ERROR [stderr] (default task-1) at org.jberet.operations.JobOperatorImpl.restart(JobOperatorImpl.java:210) 2015-02-28 08:21:37,156 ERROR [stderr] (default task-1) at com.example.batch.UnrestartableBatchTest.testRestartAfterException(UnrestartableBatchTest.java:57) {code} was (Author: cfang): Fixed in project JBeret: https://github.com/jberet/jsr352/commit/eed55070a42bbd15240e14b638fb12ea8... Also tested with attached batch-restartable.zip test against WildFly 9 snapshot. {code} 2015-02-28 08:21:37,154 INFO [com.example.batch.UnrestartableBatchTest] (default task-1) $$$ start(): jobid: 58, status: FAILED 2015-02-28 08:21:37,156 ERROR [stderr] (default task-1) javax.batch.operations.JobRestartException: JBERET000646: The job with name: unrestartable-job, execution id: 58, is configured not restartable 2015-02-28 08:21:37,156 ERROR [stderr] (default task-1) at org.jberet.operations.JobOperatorImpl.restart(JobOperatorImpl.java:210) 2015-02-28 08:21:37,156 ERROR [stderr] (default task-1) at com.example.batch.UnrestartableBatchTest.testRestartAfterException(UnrestartableBatchTest.java:57) {code} > restartable=false bach job can be restarted > ------------------------------------------- > > Key: WFLY-4390 > URL: https://issues.jboss.org/browse/WFLY-4390 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 8.2.0.Final > Reporter: Takashi Nishigaya > Assignee: Cheng Fang > Attachments: batch-restartable.zip > > > The batch job defined with restartable=false must not be restartable, after failed or stopped. > GlassFish 4.1 results in the following: > [2015-02-26T19:56:34.860+0900] [glassfish 4.1] [SEVERE] [] [] [tid: _ThreadID=25 _ThreadName=Thread-9] [timeMillis: 1424948194860] [levelValue: 1000] [[ > javax.batch.operations.JobRestartException: javax.batch.operations.JobRestartException: Job Restartable attribute is false, Job cannot be restarted. > But WildFly tries to execute the stopped or failed job. > Please check the attached test case. > wildfly: > $ mvn clean test -P wildfly-managed (or -P wildly-remote) > glassfish: > $ glassfish4/bin/asadmin start-domain > $ mvn clean test -P glassfish-remote -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4398) Upgrade jsf-impl to 2.2.10-jbossorg-2

by Farah Juma (JIRA)

Farah Juma created WFLY-4398: -------------------------------- Summary: Upgrade jsf-impl to 2.2.10-jbossorg-2 Key: WFLY-4398 URL: https://issues.jboss.org/browse/WFLY-4398 Project: WildFly Issue Type: Component Upgrade Components: JSF Reporter: Farah Juma Assignee: Farah Juma Upgrade jsf-impl to 2.2.10-jbossorg-2 to include the fix for WFLY-4349 / [JAVASERVERFACES-3797 | https://java.net/jira/browse/JAVASERVERFACES-3797]. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4017) EjbClientContextSetupProcessor uses ServiceRegistry.getService()

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4017?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4017: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1156620 > EjbClientContextSetupProcessor uses ServiceRegistry.getService() > ---------------------------------------------------------------- > > Key: WFLY-4017 > URL: https://issues.jboss.org/browse/WFLY-4017 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > As no dependencies are in place there is no guarantee this service will exist. If a deployment is present at boot time it is possible that this will not be setup correctly. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4305) Script rumbles on after error

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4305?page=com.atlassian.jira.plugin.... ] Brian Stansberry reopened WFLY-4305: ------------------------------------ I'm going to revert that PR, as I've hit both of the issues Tom described in his comment. > Script rumbles on after error > ----------------------------- > > Key: WFLY-4305 > URL: https://issues.jboss.org/browse/WFLY-4305 > Project: WildFly > Issue Type: Bug > Components: Build System > Reporter: Carlo de Wolf > Assignee: Carlo de Wolf > Fix For: 9.0.0.Beta1 > > > After a failure in the script it rumbles on. > {noformat} > (master) carlo@devel01:~/work/wildfly$ ./build.sh clean > ./tools/download-maven.sh: 20: ./tools/download-maven.sh: curl: not found > Archive: maven.zip > End-of-central-directory signature not found. Either this file is not > a zipfile, or it constitutes one disk of a multi-part archive. In the > latter case the central directory and zipfile comment will be found on > the last disk(s) of this archive. > unzip: cannot find zipfile directory in one of maven.zip or > maven.zip.zip, and cannot find maven.zip.ZIP, period. > mv: cannot stat ‘apache-maven*’: No such file or directory > build.sh: Could not locate Maven; check $MVN or $MAVEN_HOME. > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1692) XSD schema does not specify a target namespace when declaring the type element

by Alessandro Giannone (JIRA)

[ https://issues.jboss.org/browse/JGRP-1692?page=com.atlassian.jira.plugin.... ] Alessandro Giannone commented on JGRP-1692: ------------------------------------------- This issue is present again in JGroups 3.6 > XSD schema does not specify a target namespace when declaring the type element > ------------------------------------------------------------------------------ > > Key: JGRP-1692 > URL: https://issues.jboss.org/browse/JGRP-1692 > Project: JGroups > Issue Type: Feature Request > Reporter: NadirX > Assignee: Tristan Tarrant > Fix For: 3.4 > > > Validator error: Error resolving component 'ConfigType'. It was detected that 'ConfigType' has no namespace, but components with no target namespace are not referenceable from schema document 'null'. If 'ConfigType' is intended to have a namespace, perhaps a prefix needs to be provided. If it is intended that 'ConfigType' has no namespace, then an 'import' without a "namespace" attribute should be added to 'null'. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

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

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] David Lloyd commented on LOGMGR-120: ------------------------------------ Yeah that's the plan. The system property is only there to opt in so only people actually using the functionality would pay the performance penalty of checking a thread local on every log message (which will be fairly substantial). > 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 > > 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, 2 months

1
0
0 / 0

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

by Matthew Robson (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] Matthew Robson commented on LOGMGR-120: --------------------------------------- >From the usage point of view, you would want to be able to enable / use this on demand or as necessary. I think a system property would be useful to completely opt-in to this functionality, but once it's enabled, it should be dynamic. > 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 > > 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, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2015