[JBoss JIRA] (WFLY-1119) Assign an unique NodeID automatically
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on WFLY-1119:
---------------------------------
[~tomjenkinson] It looks like the default value of node-identifier is "1" currently. So it needs to check if it equals to the default value and update to the UUID if true.
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: WFLY-1119
> URL: https://issues.jboss.org/browse/WFLY-1119
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Clebert Suconic
> Assignee: Amos Feng
> Priority: Optional
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-3652) Network connection leak
by Tang Yong (JIRA)
[ https://issues.jboss.org/browse/WFLY-3652?page=com.atlassian.jira.plugin.... ]
Tang Yong commented on WFLY-3652:
---------------------------------
@Stuart Douglas I want to ask whether the issue has been fixed in 9.0.0.Alpha1? Thanks.
--Tang
> 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, 3 months
[JBoss JIRA] (WFLY-4331) EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-4331?page=com.atlassian.jira.plugin.... ]
Brad Maxwell updated WFLY-4331:
-------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/7155, https://github.com/wildfly/wildfly/pull/7216 (was: https://github.com/wildfly/wildfly/pull/7155)
> EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-4331
> URL: https://issues.jboss.org/browse/WFLY-4331
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 9.0.0.Beta1
>
>
> When invoking EJB asynchronous in different deployments and returning a POJO object, which will be retrieved using future.get, we have ClassCastException error.
> {code}
> 12:53:50,147 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /testejb-web/async: java.lang.ClassCastException: rh.test.ReturnObject cannot be cast to rh.test.ReturnObject
> at rh.test.AsyncServlet.doGet(AsyncServlet.java:29) [classes:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:259) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:246) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:75) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:165) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:737) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4331) EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-4331?page=com.atlassian.jira.plugin.... ]
Brad Maxwell reopened WFLY-4331:
--------------------------------
> EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-4331
> URL: https://issues.jboss.org/browse/WFLY-4331
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 9.0.0.Beta1
>
>
> When invoking EJB asynchronous in different deployments and returning a POJO object, which will be retrieved using future.get, we have ClassCastException error.
> {code}
> 12:53:50,147 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /testejb-web/async: java.lang.ClassCastException: rh.test.ReturnObject cannot be cast to rh.test.ReturnObject
> at rh.test.AsyncServlet.doGet(AsyncServlet.java:29) [classes:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:259) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:246) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:75) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:165) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:737) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[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)
11 years, 3 months
[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)
11 years, 3 months
[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)
11 years, 3 months