[JBoss JIRA] (WFLY-3764) Problem with Infinispan and transactions
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3764?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-3764.
------------------------------
Resolution: Duplicate Issue
Duplicate of https://issues.jboss.org/browse/WFLY-3718
> Problem with Infinispan and transactions
> -----------------------------------------
>
> Key: WFLY-3764
> URL: https://issues.jboss.org/browse/WFLY-3764
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Environment: Operating System: Redhat 6
> jdk1.7.0_51
> x86_64
> Reporter: Joel Sebastian
> Assignee: Paul Ferraro
> Labels: domain, httpsession, infinispan, transactions, web
>
> We are using Jasing CAS 3.5.2 for Single Sign On purposes deployed on a server in a Wildfly 8.0.0 Final domain (yesterday we upgraded to 8.1.0 Final).
> The application is working just fine, but in sometimes we detect this error:
> 2014-08-22 00:30:50,365 ERROR [io.undertow.request] (default task-85) UT005023: Exception handling request to /SSO/login: org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.IllegalArgumentException: Cookie name "comment" is a reserved token
> After this error the applications starts to fail with this error:
> 2014-08-22 00:31:24,387 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-91) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [15 seconds] on key [Urkr0TVHiwJ95KJnuhz9IB9n] for requestor [GlobalTransaction:<master:sso-server-1/web>:308:local]! Lock held by [GlobalTransaction:<master:sso-server-1/web>:296:local]
> 2014-08-22 00:31:24,407 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-91) ISPN000136: Execution error: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=308}, status=1} is not in a valid state to be invoking cache operations on.
> After this happens we need to restart the server, because the application cannot be restored from those errors.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4416) Cannot obtain DOMImplementationRegistry instance
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4416?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4416:
-----------------------------------
can same problem be reproduced in master as well?
> Cannot obtain DOMImplementationRegistry instance
> ------------------------------------------------
>
> Key: WFLY-4416
> URL: https://issues.jboss.org/browse/WFLY-4416
> Project: WildFly
> Issue Type: Bug
> Components: XML Frameworks
> Affects Versions: 8.2.0.Final
> Reporter: Thomas Diesler
> Assignee: Jason Greene
>
> {code}
> testDOMImplementationRegistry(org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase) Time elapsed: 0.09 sec <<< ERROR!
> java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.dom.DOMXSImplementationSourceImpl from [Module "deployment.dom-registry-test:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
> at org.w3c.dom.bootstrap.DOMImplementationRegistry.newInstance(DOMImplementationRegistry.java:182)
> at org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase.testDOMImplementationRegistry(DOMImplementationRegistryTestCase.java:52)
> {code}
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/391
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-3664) Exceptions during download of webstart libraries
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3664?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-3664.
-------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Partially Completed
As discussed on forums, majority of this problem is in original JNPL Servlet implementation.
Pino Silvaggio put together fixed version of servlet and put it on github: https://github.com/bitstrings/jnlp-servlet
With that version problems are gone.
> Exceptions during download of webstart libraries
> ------------------------------------------------
>
> Key: WFLY-3664
> URL: https://issues.jboss.org/browse/WFLY-3664
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Windows 7 (64bit), Windows Server 2012 R2 (64bit)
> Reporter: Markus Schwarz
> Assignee: Tomaz Cerar
> Priority: Minor
> Fix For: 9.0.0.Beta1
>
> Attachments: demo-src.zip, lsof.log.gz, server.log, server.log.gz
>
>
> I have a webstart application using the JnlpDownloadServlet. If the client cache is empty, launching the JNLP will download the libraries. The webstart application works as expected, but in the server logs there are many errors regarding download of the libraries.
> Just to mention: Not always the same libraries are listed with erros in the logs files. Sometimes I even got now exceptions.
> For my tests I used Wildfly 8.1.0.FINAL as well as a nightly build from 24. of July without any further changes of the configuration files (https://ci.jboss.org/hudson/job/WildFly-latest-master/).
> I tested it under Windows 7 and Windows Server 2012 R2. The demo contains an older JnlpDownloadServlet, but I tested it also with the one coming with JDK 7u65.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-2999) AJP connector request body stream is wrong mixed
by Jarno Komulainen (JIRA)
[ https://issues.jboss.org/browse/WFLY-2999?page=com.atlassian.jira.plugin.... ]
Jarno Komulainen commented on WFLY-2999:
----------------------------------------
We are probably facing this issue on Wildfly 8.2. Which undertow version contains this fix and can we upgrade wildfly 8.2 undertow module to this version?
> AJP connector request body stream is wrong mixed
> ------------------------------------------------
>
> Key: WFLY-2999
> URL: https://issues.jboss.org/browse/WFLY-2999
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Environment: Apahce HTTPD 2.2.23 + MOD_CLUSTER 1.3 Final + WildFly 8 Final
> Reporter: JuYeon Yu
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Alpha1
>
>
> Seem to have a problem with the AJP Connector.
> When client(Browser) send request has many parameter, sometime received content is different.
> ex)
> Request Body is:
> dataJson={"crfpage_type":["CRF"],"qst_rowno":["7148#0#0","7141#0#0","7143#0#0","7144#0#0","7145#0#0","7146#0#0","7147#0#0","7123#0#0","7125#0#0","7126#0#0","7127#0#0","7128#0#0","7129#0#0","7130#0#0","7131#0#0","7132#0#0","7133#0#0","7134#0#0","7135#0#0","7136#0#0","7137#0#0","7138#0#0","7139#0#0","7140#0#0","7117#0#0","7119#0#0","7120#0#0","7121#0#0","7122#0#0"],"item_7148_16445_0_0":[""],"_item_7141_16466_0_0":[""],"item_7143_16462_0_0":["RBC"],"item_7143_16463_0_0":[""],"item_7143_16464_0_0":[""],"item_7143_16464_0_0_r":[""],"item_7143_16465_0_0":[""],"item_7144_16458_0_0":["Hemoglobin"],"item_7144_16459_0_0":[""],"item_7144_16460_0_0":[""],"item_7144_16460_0_0_r":[""],"item_7144_16461_0_0":[""],"item_7145_16454_0_0":["Hematocrit"],"item_7145_16455_0_0":[""],"item_7145_16456_0_0":[""],"item_7145_16456_0_0_r":[""],"item_7145_16457_0_0":[""],"item_7146_16450_0_0":["Platelet"],"item_7146_16451_0_0":[""],"item_7146_16452_0_0":[""],"item_7146_16452_0_0_r":[""],"item_7146_16453_0_0":[""],"item_7147_16446_0_0":["WBC"],"item_7147_16447_0_0":[""],"item_7147_16448_0_0":[""],"item_7147_16448_0_0_r":[""],"item_7147_16449_0_0":[""],"_item_7123_16531_0_0":[""],"item_7125_16527_0_0":["Calcium"],"item_7125_16528_0_0":[""],"item_7125_16529_0_0":[""],"item_7125_16529_0_0_r":[""],"item_7125_16530_0_0":[""],"item_7126_16523_0_0":["Sodium"],"item_7126_16524_0_0":[""],"item_7126_16525_0_0":[""],"item_7126_16525_0_0_r":[""],"item_7126_16526_0_0":[""],"item_7127_16519_0_0":["Potassium"],"item_7127_16520_0_0":[""],"item_7127_16521_0_0":[""],"item_7127_16521_0_0_r":[""],"item_7127_16522_0_0":[""],"item_7128_16515_0_0":["Chloride"],"item_7128_16516_0_0":[""],"item_7128_16517_0_0":[""],"item_7128_16517_0_0_r":[""],"item_7128_16518_0_0":[""],"item_7129_16511_0_0":["Creatinine"],"item_7129_16512_0_0":[""],"item_7129_16513_0_0":[""],"item_7129_16513_0_0_r":[""],"item_7129_16514_0_0":[""],"item_7130_16507_0_0":["BUN"],"item_7130_16508_0rl=/cs8635_sit_11_01/crf-submit/S4Z068/3015 , dataJson={"crfpage_type":["CRF"],"qst_rowno":["7148#0#0","7141#0#0","7143#0#0","7144#0#0","7145#0#0","7146#0#0","7147#0#0","7123#0#0","7125#0#0","7126#0#0","7127#0#0","7128#0#0","7129#0#0","7130#0#0","7131#0#0","7132#0#0","7133#0#0","7134#0#0","7135#0#0","7136#0#0","7137#0#0","7138#0#0","7139#0#0","7140#0#0","7117#0#0","7119#0#0","7120#0#0","7121#0#0","7122#0#0"],"item_7148_16445_0_0":[""],"_item_7141_16466_0_0":[""],"item_7143_16462_0_0":["RBC"],"item_7143_16463_0_0":[""],"item_7143_16464_0_0":[""],"item_7143_16464_0_0_r":[""],"item_7143_16465_0_0":[""],"item_7144_16458_0_0":["Hemoglobin"],"item_7144_16459_0_0":[""],"item_7144_16460_0_0":[""],"item_7144_16460_0_0_r":[""],"item_7144_16461_0_0":[""],"item_7145_16454_0_0":["Hematocrit"],"item_7145_16455_0_0":[""],"item_7145_16456_0_0":[""],"item_7145_16456_0_0_r":[""],"item_7145_16457_0_0":[""],"item_7146_16450_0_0":["Platelet"],"item_7146_16451_0_0":[""],"item_7146_16452_0_0":[""],"item_7146_16452_0_0_r":[""],"item_7146_16453_0_0":[""],"item_7147_16446_0_0":["WBC"],"item_7147_16447_0_0":[""],"item_7147_16448_0_0":[""],"item_7147_16448_0_0_r":[""],"item_7147_16449_0_0":[""],"_item_7123_16531_0_0":[""],"item_7125_16527_0_0":["Calcium"],"item_7125_16528_0_0":[""],"item_7125_16529_0_0":[""],"item_7125_16529_0_0_r":[""],"item_7125_16530_0_0":[""],"item_7126_16523_0_0":["Sodium"],"item_7126_16524_0_0":[""],"item_7126_16525_0_0":[""],"item_7126_16525_0_0_r":[""],"item_7126_16526_0_0":[""],"item_7127_16519_0_0":["Potassium"],"item_7127_16520_0_0":[""],"item_7127_16521_0_0":[""],"item_7127_16521_0_0_r":[""],"item_7127_16522_0_0":[""],"item_7128_16515_0_0":["Chloride"],"item_7128_16516_0_0":[""],"item_7128_16517_0_0":[""],"item_7128_16517_0_0_r":[""],"item_7128_16518_0_0":[""],"item_7129_16511_0_0":["Creatinine"],"item_7129_16512_0_0":[""],"item_7129_16513_0_0":[""],"item_7129_16513_0_0_r":[""],"item_7129_16514_0_0":[""],"item_7130_16507_0_0":["BUN"],"item_7130_16508_0rl=/cs8635_sit_11_01/crf-submit/S4Z068/3015 , dataJson={"crfpage_type":["CRF"],"qst_rowno":["7148#0#0","7141#0#0","7143#0#0","7144#0#0","7145#0#0","7146#0#0","7147#0#0","7123#0#0","7125#0#0","7126#0#0","7127#0#0","7128#0#0","7129#0#0","7130#0#0","7131#0#0","7132#0#0","7133#0#0","7134#0#0","7135#0#0","7136#0#0","7137#0#0","7138#0#0","7139#0#0","7140#0#0","7117#0#0","7119#0#0","7120#0#0","7121#0#0","7122#0#0"],"item_7148_16445_0_0":[""],"_item_7141_16466_0_0":[""],"item_7143_16462_0_0":["RBC"],"item_7143_16463_0_0":[""],"item_7143_16464_0_0":[""],"item_7143_16464_0_0_r":[""],"item_7143_16465_0_0":[""],"item_7144_16458_0_0":["Hemoglobin"],"item_7144_16459_0_0":[""],"item_7144_16460_0_0":[""],"item_7144_16460_0_0_r":[""],"item_7144_16461_0_0":[""],"item_7145_16454_0_0":["Hematocrit"],"item_7145_16455_0_0":[""],"item_7145_16456_0_0":[""],"item_7145_16456_0_0_r":[""],"item_7145_16457_0_0":[""],"item_7146_16450_0_0":["Platelet"],"item_7146_16451_0_0":[""],"item_7146_16452_0_0":[""],"item_7146_16452_0_0_r":[""],"item_7146_16453_0_0":[""],"item_7147_16446_0_0":["WBC"],"item_7147_16447_0_0":[""],"item_7147_16448_0_0":[""],"item_7147_16448_0_0_r":[""],"item_7147_16449_0_0":[""],"_item_7123_16531_0_0":[""],"item_7125_16527_0_0":["Calcium"],"item_7125_16528_0_0":[""],"item_7125_16529_0_0":[""],"item_7125_16529_0_0_r":[""],"item_7125_16530_0_0":[""],"item_7126_16523_0_0":["Sodium"],"item_7126_16524_0_0":[""],"item_7126_16525_0_0":[""],"item_7126_16525_0_0_r":[""],"item_7126_16526_0_0":[""],"item_7127_16519_0_0":["Potassium"],"item_7127_16520_0_0":[""],"item_7127_16521_0_0":[""],"item_7127_16521_0_0_r":[""],"item_7127_16522_0_0":[""],"item_7128_16515_0_0":["Chloride"],"item_7128_16516_0_0":[""],"item_7128_16517_0_0":[""],"item_7128_16517_0_0_r":[""],"item_7128_16518_0_0":[""],"item_7129_16511_0_0":["Creatinine"],"item_7129_16512_0_0":[""],"item_7129_16513_0_0":[""],"item_7129_16513_0_0_r":[""],"item_7129_16514_0_0":[""],"item_7130_16507_0_0":["BUN"],"item_7130_16508_03A[""],"item_7121_16536_0_0":["Protein"],"item_7121_16537_0_0":[""],"item_7121_16539_0_0":[""],"item_7122_16532_0_0":["Glucose"],"item_7122_16533_0_0":[""],"item_7122_16535_0_0":[""]}
> Received is:
> dataJson={"crfpage_type":["CRF"],"qst_rowno":["7148#0#0","7141#0#0","7143#0#0","7144#0#0","7145#0#0","7146#0#0","7147#0#0","7123#0#0","7125#0#0","7126#0#0","7127#0#0","7128#0#0","7129#0#0","7130#0#0","7131#0#0","7132#0#0","7133#0#0","7134#0#0","7135#0#0","7136#0#0","7137#0#0","7138#0#0","7139#0#0","7140#0#0","7117#0#0","7119#0#0","7120#0#0","7121#0#0","7122#0#0"],"item_7148_16445_0_0":[""],"_item_7141_16466_0_0":[""],"item_7143_16462_0_0":["RBC"],"item_7143_16463_0_0":[""],"item_7143_16464_0_0":[""],"item_7143_16464_0_0_r":[""],"item_7143_16465_0_0":[""],"item_7144_16458_0_0":["Hemoglobin"],"item_7144_16459_0_0":[""],"item_7144_16460_0_0":[""],"item_7144_16460_0_0_r":[""],"item_7144_16461_0_0":[""],"item_7145_16454_0_0":["Hematocrit"],"item_7145_16455_0_0":[""],"item_7145_16456_0_0":[""],"item_7145_16456_0_0_r":[""],"item_7145_16457_0_0":[""],"item_7146_16450_0_0":["Platelet"],"item_7146_16451_0_0":[""],"item_7146_16452_0_0":[""],"item_7146_16452_0_0_r":[""],"item_7146_16453_0_0":[""],"item_7147_16446_0_0":["WBC"],"item_7147_16447_0_0":[""],"item_7147_16448_0_0":[""],"item_7147_16448_0_0_r":[""],"item_7147_16449_0_0":[""],"_item_7123_16531_0_0":[""],"item_7125_16527_0_0":["Calcium"],"item_7125_16528_0_0":[""],"item_7125_16529_0_0":[""],"item_7125_16529_0_0_r":[""],"item_7125_16530_0_0":[""],"item_7126_16523_0_0":["Sodium"],"item_7126_16524_0_0":[""],"item_7126_16525_0_0":[""],"item_7126_16525_0_0_r":[""],"item_7126_16526_0_0":[""],"item_7127_16519_0_0":["Potassium"],"item_7127_16520_0_0":[""],"item_7127_16521_0_0":[""],"item_7127_16521_0_0_r":[""],"item_7127_16522_0_0":[""],"item_7128_16515_0_0":["Chloride"],"item_7128_16516_0_0":[""],"item_7128_16517_0_0":[""],"item_7128_16517_0_0_r":[""],"item_7128_16518_0_0":[""],"item_7129_16511_0_0":["Creatinine"],"item_7129_16512_0_0":[""],"item_7129_16513_0_0":[""],"item_7129_16513_0_0_r":[""],"item_7129_16514_0_0":[""],"item_7130_16507_0_0":["BUN"],"item_7130_16508_0rl=/cs8635_sit_11_01/crf-submit/S4Z068/3015 , dataJson={"crfpage_type":["CRF"],"qst_rowno":["7148#0#0","7141#0#0","7143#0#0","7144#0#0","7145#0#0","7146#0#0","7147#0#0","7123#0#0","7125#0#0","7126#0#0","7127#0#0","7128#0#0","7129#0#0","7130#0#0","7131#0#0","7132#0#0","7133#0#0","7134#0#0","7135#0#0","7136#0#0","7137#0#0","7138#0#0","7139#0#0","7140#0#0","7117#0#0","7119#0#0","7120#0#0","7121#0#0","7122#0#0"],"item_7148_16445_0_0":[""],"_item_7141_16466_0_0":[""],"item_7143_16462_0_0":["RBC"],"item_7143_16463_0_ataJson={"crfpage_type":["CRF"],"qst_rowno":["7148#0#0","7141#0#0","7143#0#0","7144#0#0","7145#0#0","7146#0#0","7147#0#0","7123#0#0","7125#0#0","7126#0#0","7127#0#0","7128#0#0","7129#0#0","7130#0#0","7131#0#0","7132#0#0","7133#0#0","7134#0#0","7135#0#0","7136#0#0","7137#0#0","7138#0#0","7139#0#0","7140#0#0","7117#0#0","7119#0#0","7120#0#0","7121#0#0","7122#0#0"],"item_7148_16445_0_0":[""],"_item_7141_16466_0_0":[""],"item_7143_16462_0_0":["RBC"],"item_7143_16463_0_0":[""],"item_7143_16464_0_0":[""],"item_7143_16464_0_0_r":[""],"item_7143_16465_0_0":[""],"item_7144_16458_0_0":["Hemoglobin"],"item_7144_16459_0_0":[""],"item_7144_16460_0_0":[""],"item_7144_16460_0_0_r":[""],"item_7144_16461_0_0":[""],"item_7145_16454_0_0":["Hematocrit"],"item_7145_16455_0_0":[""],"item_7145_16456_0_0":[""],"item_7145_16456_0_0_r":[""],"item_7145_16457_0_0":[""],"item_7146_16450_0_0":["Platelet"],"item_7146_16451_0_0":[""],"item_7146_16452_0_0":[""],"item_7146_16452_0_0_r":[""],"item_7146_16453_0_0":[""],"item_7147_16446_0_0":["WBC"],"item_7147_16447_0_0":[""],"item_7147_16448_0_0":[""],"item_7147_16448_0_0_r":[""],"item_7147_16449_0_0":[""],"_item_7123_16531_0_0":[""],"item_7125_16527_0_0":["Calcium"],"item_7125_16528_0_0":[""],"item_7125_16529_0_0":[""],"item_7125_16529_0_0_r":[""],"item_7125_16530_0_0":[""],"item_7126_16523_0_0":["Sodium"],"item_7126_16524_0_0":[""],"item_7126_16525_0_0":[""],"item_7126_16525_0_0_r":[""],"item_7126_16526_0_0":[""],"item_7127_16519_0_0":["Potassium"],"item_7127_16520_0_0":[""],"item_7127_16521_0_0":[""],"item_7127_16521_0_0_r":[""],"item_7127_16522_0_0":[""],"item_7128_16515_0_0":["Chloride"],"item_7128_16516_0_0":[""],"item_7128_16517_0_0":[""],"item_7128_16517_0_0_r":[""],"item_7128_16518_0_0":[""],"item_7129_16511_0_0":["Creatinine"],"item_7129_16512_0_0":[""],"item_7129_16513_0_0":[""],"item_7129_16513_0_0_r":[""],"item_7129_16514_0_0":[""],"item_7130_16507_0_0":["BUN"],"item_7130_16508_0rl=/cs8635_sit_11_01/crf-submit/S4Z068/3015 , dataJson={"crfpage_type":["CRF"],"qst_rowno":["7148#0#0","7141#0#0","7143#0#0","7144#0#0","7145#0#0","7146#0#0","7147#0#0","7123#0#0","7125#0#0","7126#0#0","7127#0#0","7128#0#0","7129#0#0","7130#0#0","7131#0#0","7132#0#0","7133#0#0","7134#0#0","7135#0#0","7136#0#0","7137#0#0","7138#0#0","7139#0#0","7140#0#0","7117#0#0","7119#0#0","7120#0#0","7121#0#0","7122#0#0"],"item_7148_16445_0_0":[""],"_item_7141_16466_0_0":[""],"item_7143_16462_0_0":["RBC"],"item_7143_16463_0_
> I test use HTTP Connector same case, but it is normal(request and received is same)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4413) Network connection leak in asynchronous servlet
by Ron Peng (JIRA)
[ https://issues.jboss.org/browse/WFLY-4413?page=com.atlassian.jira.plugin.... ]
Ron Peng commented on WFLY-4413:
--------------------------------
Maybe when end the request, some exceptions are thrown, the operation "attempt to read again" is missed.
> Network connection leak in asynchronous servlet
> -----------------------------------------------
>
> Key: WFLY-4413
> URL: https://issues.jboss.org/browse/WFLY-4413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Environment: Linux
> Reporter: jeremy_lv lv
> Assignee: Stuart Douglas
> Priority: Blocker
> Labels: undertow
>
> {panel:title=Phenomenon|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> When the connection is suddenly terminated during the period we access the asynchronous servlet application, the connection will be leaked. However, the connection won't be leak when we access the synchronous servlet application.
> {panel}
> *Some of the stacktrace are as follows:*
> {panel:title=Stacktrace|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> 14:34:23,751 ERROR [io.undertow.request] (default task-22) Blocking request fail
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
> at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java
> at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java
> at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(As
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_25]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:94) [rt.jar:1.7.0
> at sun.nio.ch.IOUtil.write(IOUtil.java:51) [rt.jar:1.7.0_25]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466) [rt.ja
> at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
> at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(Htt
> at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpRespon
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(Abstr
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkCha
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStre
> at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputS
> at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
> ... 6 more
> {panel}
> *Here's the test war code you can used to reproduce this phenomenon:*
> {code:title=AsyncDemoServlet.java|borderStyle=solid}
> import java.io.IOException;
> import javax.servlet.AsyncContext;
> import javax.servlet.ServletException;
> import javax.servlet.annotation.WebServlet;
> import javax.servlet.http.HttpServlet;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
> @WebServlet(urlPatterns="/asyncDemoServlet",asyncSupported=true)
> public class AsyncDemoServlet extends HttpServlet {
> private static final long serialVersionUID = 1L;
> protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> response.setContentType("text/html;charset=UTF-8");
> //Execute the business logic in sub-thread.
> AsyncContext ctx = request.startAsync();
> new Thread(new Executor(ctx)).start();
> }
> protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> doGet(request, response);
> }
> public class Executor implements Runnable {
> private AsyncContext ctx = null;
> public Executor(AsyncContext ctx){
> this.ctx = ctx;
> }
> public void run(){
> try {
> //wait for 5 seconds to simulate the business logic.
> Thread.sleep(5000);
> ctx.complete();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4419) Dependency on a deployed CDI module - beans are not injected
by Dirk Buchhorn (JIRA)
Dirk Buchhorn created WFLY-4419:
-----------------------------------
Summary: Dependency on a deployed CDI module - beans are not injected
Key: WFLY-4419
URL: https://issues.jboss.org/browse/WFLY-4419
Project: WildFly
Issue Type: Feature Request
Components: CDI / Weld
Affects Versions: 8.2.0.Final
Reporter: Dirk Buchhorn
Assignee: Stuart Douglas
I want to deploy two modules to wildfly 8.2.0 The module-a contains beans (and later CDI producer and other stuff) and module-b use this beans. Beans from module-a should be injected with CDI in module-b (There is a beans.xml in both modules.). All works fine if the module-a is direct referenced as dependency like this:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<dependencies>
<module name="deployment.module-a-1.0.0.jar" meta-inf="import" />
</dependencies>
</deployment>
</jboss-deployment-structure>
But the dependency to module-a should be without to know the deployed version, so I tried to set a module alias and (or) to re-export module-a under a different name like this.
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<module-alias name="deployment.module-a-alias" />
</deployment>
</jboss-deployment-structure>
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<module name="deployment.module-a">
<module-alias name="deployment.module-a-alias" />
<dependencies>
<module name="deployment.module-a-1.0.0.jar" export="true" meta-inf="export" />
</dependencies>
</module>
</jboss-deployment-structure>
But either the module alias or a re-export under a new module name worked. The reported exception is always:
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type XYZ with qualifiers @Default
The module alias fit my requirements and I guess is should work with CDI but it dosn't.
Two questions:
- Why CDI don't work with module alias and module re-export?
- How to deal with dependencies and module versions?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4413) Network connection leak in asynchronous servlet
by jeremy_lv lv (JIRA)
[ https://issues.jboss.org/browse/WFLY-4413?page=com.atlassian.jira.plugin.... ]
jeremy_lv lv updated WFLY-4413:
-------------------------------
Description:
{panel:title=Phenomenon|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
When the connection is suddenly terminated during the period we access the asynchronous servlet application, the connection will be leaked. However, the connection won't be leak when we access the synchronous servlet application.
{panel}
*Some of the stacktrace are as follows:*
{panel:title=Stacktrace|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
14:34:23,751 ERROR [io.undertow.request] (default task-22) Blocking request fail
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java
at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java
at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(As
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_25]
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:94) [rt.jar:1.7.0
at sun.nio.ch.IOUtil.write(IOUtil.java:51) [rt.jar:1.7.0_25]
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466) [rt.ja
at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(Htt
at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpRespon
at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(Abstr
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkCha
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStre
at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputS
at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
... 6 more
{panel}
*Here's the test war code you can used to reproduce this phenomenon:*
{code:title=AsyncDemoServlet.java|borderStyle=solid}
import java.io.IOException;
import javax.servlet.AsyncContext;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
@WebServlet(urlPatterns="/asyncDemoServlet",asyncSupported=true)
public class AsyncDemoServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
//Execute the business logic in sub-thread.
AsyncContext ctx = request.startAsync();
new Thread(new Executor(ctx)).start();
}
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
doGet(request, response);
}
public class Executor implements Runnable {
private AsyncContext ctx = null;
public Executor(AsyncContext ctx){
this.ctx = ctx;
}
public void run(){
try {
//wait for 5 seconds to simulate the business logic.
Thread.sleep(5000);
ctx.complete();
} catch (Exception e) {
e.printStackTrace();
}
}
}
}
{code}
was:
{panel:title=Phenomenon|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
When the connection is suddenly terminated during the period we access the asynchronous servlet application, the connection will be leaked. However, the connection won't be leak when we access the synchronous servlet application.
{panel}
*Some of the stacktrace are as follows:*
{panel:title=Stacktrace|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
14:34:23,751 ERROR [io.undertow.request] (default task-22) Blocking request fail
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java
at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java
at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(As
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_25]
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:94) [rt.jar:1.7.0
at sun.nio.ch.IOUtil.write(IOUtil.java:51) [rt.jar:1.7.0_25]
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466) [rt.ja
at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(Htt
at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpRespon
at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(Abstr
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkCha
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStre
at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputS
at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
... 6 more
{panel}
*Here's the test war code you can used to reproduce this phenomenon:*
{code:title=AsyncDemoServlet.java|borderStyle=solid}
package com.suning.esb.test;
import java.io.IOException;
import javax.servlet.AsyncContext;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
@WebServlet(urlPatterns="/asyncDemoServlet",asyncSupported=true)
public class AsyncDemoServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
//Execute the business logic in sub-thread.
AsyncContext ctx = request.startAsync();
new Thread(new Executor(ctx)).start();
}
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
doGet(request, response);
}
public class Executor implements Runnable {
private AsyncContext ctx = null;
public Executor(AsyncContext ctx){
this.ctx = ctx;
}
public void run(){
try {
//wait for 5 seconds to simulate the business logic.
Thread.sleep(5000);
ctx.complete();
} catch (Exception e) {
e.printStackTrace();
}
}
}
}
{code}
> Network connection leak in asynchronous servlet
> -----------------------------------------------
>
> Key: WFLY-4413
> URL: https://issues.jboss.org/browse/WFLY-4413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Environment: Linux
> Reporter: jeremy_lv lv
> Assignee: Stuart Douglas
> Priority: Blocker
> Labels: undertow
>
> {panel:title=Phenomenon|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> When the connection is suddenly terminated during the period we access the asynchronous servlet application, the connection will be leaked. However, the connection won't be leak when we access the synchronous servlet application.
> {panel}
> *Some of the stacktrace are as follows:*
> {panel:title=Stacktrace|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> 14:34:23,751 ERROR [io.undertow.request] (default task-22) Blocking request fail
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
> at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java
> at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java
> at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(As
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_25]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:94) [rt.jar:1.7.0
> at sun.nio.ch.IOUtil.write(IOUtil.java:51) [rt.jar:1.7.0_25]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466) [rt.ja
> at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
> at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(Htt
> at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpRespon
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(Abstr
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkCha
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStre
> at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputS
> at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
> ... 6 more
> {panel}
> *Here's the test war code you can used to reproduce this phenomenon:*
> {code:title=AsyncDemoServlet.java|borderStyle=solid}
> import java.io.IOException;
> import javax.servlet.AsyncContext;
> import javax.servlet.ServletException;
> import javax.servlet.annotation.WebServlet;
> import javax.servlet.http.HttpServlet;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
> @WebServlet(urlPatterns="/asyncDemoServlet",asyncSupported=true)
> public class AsyncDemoServlet extends HttpServlet {
> private static final long serialVersionUID = 1L;
> protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> response.setContentType("text/html;charset=UTF-8");
> //Execute the business logic in sub-thread.
> AsyncContext ctx = request.startAsync();
> new Thread(new Executor(ctx)).start();
> }
> protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> doGet(request, response);
> }
> public class Executor implements Runnable {
> private AsyncContext ctx = null;
> public Executor(AsyncContext ctx){
> this.ctx = ctx;
> }
> public void run(){
> try {
> //wait for 5 seconds to simulate the business logic.
> Thread.sleep(5000);
> ctx.complete();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4413) Network connection leak in asynchronous servlet
by jeremy_lv lv (JIRA)
[ https://issues.jboss.org/browse/WFLY-4413?page=com.atlassian.jira.plugin.... ]
jeremy_lv lv edited comment on WFLY-4413 at 3/11/15 4:10 AM:
-------------------------------------------------------------
Hi, [~swd847]
{quote}
What platform are you on?
{quote}
*OS*: Red Hat Enterprise Linux Server release 5.5
*undertow version*: undertow-1.0.15.Final
*wildfly version*: 8.1.0 Final.
*Browser*: IE 8
The similar phenomenon also can be reproduced in Wildfly 8.2.0 Final.
{quote}
I see the socket sitting in CLOSE_WAIT, until ctx.complete() is called and then the connection is closed. Which is the expected behaviour (the socket close notification won't be received until we attempt to read again, which does not happen until the current request is done).
{quote}
In my reproduced case, the socket turned into close before ctx.complete() is called because we have pressed "Esc" button before ctx.complete() is called. Then there will be some exceptions thrown when invoke the ctx.complete() and the sockets are kept open by the JVM. Then you can use "lsof -p wildfly_pid | grep "can't identify protocol" |wc -l" to check out the socket leak number kept by Wildfly's JVM.
was (Author: jeremy_lv):
Hi, [~swd847]
{quote}
What platform are you on?
{quote}
*OS*: Red Hat Enterprise Linux Server release 5.5
*undertow version*: undertow-1.0.15.Final
*wildfly version*: 8.1.0 Final.
The similar phenomenon also can be reproduced in Wildfly 8.2.0 Final.
{quote}
I see the socket sitting in CLOSE_WAIT, until ctx.complete() is called and then the connection is closed. Which is the expected behaviour (the socket close notification won't be received until we attempt to read again, which does not happen until the current request is done).
{quote}
In my reproduced case, the socket turned into close before ctx.complete() is called because we have pressed "Esc" button before ctx.complete() is called. Then there will be some exceptions thrown when invoke the ctx.complete() and the sockets are kept open by the JVM. Then you can use "lsof -p wildfly_pid | grep "can't identify protocol" |wc -l" to check out the socket leak number kept by Wildfly's JVM.
> Network connection leak in asynchronous servlet
> -----------------------------------------------
>
> Key: WFLY-4413
> URL: https://issues.jboss.org/browse/WFLY-4413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Environment: Linux
> Reporter: jeremy_lv lv
> Assignee: Stuart Douglas
> Priority: Blocker
> Labels: undertow
>
> {panel:title=Phenomenon|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> When the connection is suddenly terminated during the period we access the asynchronous servlet application, the connection will be leaked. However, the connection won't be leak when we access the synchronous servlet application.
> {panel}
> *Some of the stacktrace are as follows:*
> {panel:title=Stacktrace|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> 14:34:23,751 ERROR [io.undertow.request] (default task-22) Blocking request fail
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
> at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java
> at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java
> at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(As
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_25]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:94) [rt.jar:1.7.0
> at sun.nio.ch.IOUtil.write(IOUtil.java:51) [rt.jar:1.7.0_25]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466) [rt.ja
> at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
> at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(Htt
> at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpRespon
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(Abstr
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkCha
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStre
> at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputS
> at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
> ... 6 more
> {panel}
> *Here's the test war code you can used to reproduce this phenomenon:*
> {code:title=AsyncDemoServlet.java|borderStyle=solid}
> package com.suning.esb.test;
> import java.io.IOException;
> import javax.servlet.AsyncContext;
> import javax.servlet.ServletException;
> import javax.servlet.annotation.WebServlet;
> import javax.servlet.http.HttpServlet;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
> @WebServlet(urlPatterns="/asyncDemoServlet",asyncSupported=true)
> public class AsyncDemoServlet extends HttpServlet {
> private static final long serialVersionUID = 1L;
> protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> response.setContentType("text/html;charset=UTF-8");
> //Execute the business logic in sub-thread.
> AsyncContext ctx = request.startAsync();
> new Thread(new Executor(ctx)).start();
> }
> protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> doGet(request, response);
> }
> public class Executor implements Runnable {
> private AsyncContext ctx = null;
> public Executor(AsyncContext ctx){
> this.ctx = ctx;
> }
> public void run(){
> try {
> //wait for 5 seconds to simulate the business logic.
> Thread.sleep(5000);
> ctx.complete();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4413) Network connection leak in asynchronous servlet
by jeremy_lv lv (JIRA)
[ https://issues.jboss.org/browse/WFLY-4413?page=com.atlassian.jira.plugin.... ]
jeremy_lv lv edited comment on WFLY-4413 at 3/11/15 4:05 AM:
-------------------------------------------------------------
Hi, [~swd847]
{quote}
What platform are you on?
{quote}
*OS*: Red Hat Enterprise Linux Server release 5.5
*undertow version*: undertow-1.0.15.Final
*wildfly version*: 8.1.0 Final.
The similar phenomenon also can be reproduced in Wildfly 8.2.0 Final.
{quote}
I see the socket sitting in CLOSE_WAIT, until ctx.complete() is called and then the connection is closed. Which is the expected behaviour (the socket close notification won't be received until we attempt to read again, which does not happen until the current request is done).
{quote}
In my reproduced case, the socket turned into close before ctx.complete() is called because we have pressed "Esc" button before ctx.complete() is called. Then there will be some exceptions thrown when invoke the ctx.complete() and the sockets are kept open by the JVM. Then you can use "lsof -p wildfly_pid | grep "can't identify protocol" |wc -l" to check out the socket leak number kept by Wildfly's JVM.
was (Author: jeremy_lv):
{quote}
What platform are you on?
{quote}
*OS*: Red Hat Enterprise Linux Server release 5.5
*undertow version*: undertow-1.0.15.Final
*wildfly version*: 8.1.0 Final.
The similar phenomenon also can be reproduced in Wildfly 8.2.0 Final.
{quote}
I see the socket sitting in CLOSE_WAIT, until ctx.complete() is called and then the connection is closed. Which is the expected behaviour (the socket close notification won't be received until we attempt to read again, which does not happen until the current request is done).
{quote}
In my reproduced case, the socket turned into close before ctx.complete() is called because we have pressed "Esc" button before ctx.complete() is called. Then there will be some exceptions thrown when invoke the ctx.complete() and the sockets are kept open by the JVM. Then you can use "lsof -p wildfly_pid | grep "can't identify protocol" |wc -l" to check out the socket leak number kept by Wildfly's JVM.
> Network connection leak in asynchronous servlet
> -----------------------------------------------
>
> Key: WFLY-4413
> URL: https://issues.jboss.org/browse/WFLY-4413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Environment: Linux
> Reporter: jeremy_lv lv
> Assignee: Stuart Douglas
> Priority: Blocker
> Labels: undertow
>
> {panel:title=Phenomenon|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> When the connection is suddenly terminated during the period we access the asynchronous servlet application, the connection will be leaked. However, the connection won't be leak when we access the synchronous servlet application.
> {panel}
> *Some of the stacktrace are as follows:*
> {panel:title=Stacktrace|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> 14:34:23,751 ERROR [io.undertow.request] (default task-22) Blocking request fail
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
> at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java
> at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java
> at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(As
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_25]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:94) [rt.jar:1.7.0
> at sun.nio.ch.IOUtil.write(IOUtil.java:51) [rt.jar:1.7.0_25]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466) [rt.ja
> at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
> at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(Htt
> at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpRespon
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(Abstr
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkCha
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStre
> at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputS
> at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
> ... 6 more
> {panel}
> *Here's the test war code you can used to reproduce this phenomenon:*
> {code:title=AsyncDemoServlet.java|borderStyle=solid}
> package com.suning.esb.test;
> import java.io.IOException;
> import javax.servlet.AsyncContext;
> import javax.servlet.ServletException;
> import javax.servlet.annotation.WebServlet;
> import javax.servlet.http.HttpServlet;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
> @WebServlet(urlPatterns="/asyncDemoServlet",asyncSupported=true)
> public class AsyncDemoServlet extends HttpServlet {
> private static final long serialVersionUID = 1L;
> protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> response.setContentType("text/html;charset=UTF-8");
> //Execute the business logic in sub-thread.
> AsyncContext ctx = request.startAsync();
> new Thread(new Executor(ctx)).start();
> }
> protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> doGet(request, response);
> }
> public class Executor implements Runnable {
> private AsyncContext ctx = null;
> public Executor(AsyncContext ctx){
> this.ctx = ctx;
> }
> public void run(){
> try {
> //wait for 5 seconds to simulate the business logic.
> Thread.sleep(5000);
> ctx.complete();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months