[JBoss JIRA] (WFLY-4413) Network connection leak in asynchronous servlet
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4413?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4413:
--------------------------------------
If you end the request Undertow will attempt to read again (as it will try and read the next request). If you massively increase the async timeout and never end the request then the connection will stay open indefinitely, which is the expected behaviour.
> 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)
9 years, 7 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:
--------------------------------
Hi, [~swd847]
As you said, if we do not attempt to read again(I think it could happen),
the socket close notification will never be received, and the socket will never be closed
> 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)
9 years, 7 months
[JBoss JIRA] (WFLY-4418) ManagedTasks not properly wrapped by ManagedScheduledExecutorService
by Eduardo Martins (JIRA)
Eduardo Martins created WFLY-4418:
-------------------------------------
Summary: ManagedTasks not properly wrapped by ManagedScheduledExecutorService
Key: WFLY-4418
URL: https://issues.jboss.org/browse/WFLY-4418
Project: WildFly
Issue Type: Bug
Components: EE
Reporter: Eduardo Martins
Assignee: Eduardo Martins
There are no callbacks, or custom behaviour through execution properties, for ManagedTasks scheduled in ManagedScheduledExecutorService. That happens because ManagedScheduledExecutorService wraps these tasks but the wrapping class does not implements ManagedTask.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (WFLY-4417) CNFE on EE Concurrency Contextual Proxies Serialization
by Eduardo Martins (JIRA)
Eduardo Martins created WFLY-4417:
-------------------------------------
Summary: CNFE on EE Concurrency Contextual Proxies Serialization
Key: WFLY-4417
URL: https://issues.jboss.org/browse/WFLY-4417
Project: WildFly
Issue Type: Bug
Components: EE
Reporter: Eduardo Martins
Assignee: Eduardo Martins
A CNFE is thrown when deserialising a contextual proxy object made by the Context Service, the TransactionSetupProvider impl class (in transactions module) is not seen by deployments.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (JBAS-9570) (javax.resource.ResourceException: Interrupted while requesting permit! Waited 0 ms,
by usman hassan (JIRA)
[ https://issues.jboss.org/browse/JBAS-9570?page=com.atlassian.jira.plugin.... ]
usman hassan updated JBAS-9570:
-------------------------------
Summary: (javax.resource.ResourceException: Interrupted while requesting permit! Waited 0 ms, (was: Envirnment:)
Description:
I have a issue in my jboss where my current transaction gets
interrupted. I am getting the following error from my logs.
2015-03-10 07:13:15,911 FATAL [SDES.HubManager.DynamicTransactionDelegate] [01A713400A03140CD99F6EC4013F8919] finderException while stamping delivery Find failed: org.jboss.util.NestedSQLException: Interrupted while requesting permit! Waited 0 ms, invocation time: 1425957195897; - nested throwable: (javax.resource.ResourceException: Interrupted while requesting permit! Waited 0 ms, invocation time: 1425957195897
In addition to above below connection factory not bound error is also frequent in the logs
2015-03-09 14:48:51,386 WARN [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] javax.naming.NameNotFoundException: XAConnectionFactory not bound
Effect on Application:
Even though the above errors are there but application seems to be working fine for some days but it suddenly starts misbehaving when the load is high.
Any suggestion/hint to resolve the issue will be more then welcomed. Thanks in Advance.
Environment:
Jboss: 3.2.5
Jdk: 1.4
> (javax.resource.ResourceException: Interrupted while requesting permit! Waited 0 ms,
> ------------------------------------------------------------------------------------
>
> Key: JBAS-9570
> URL: https://issues.jboss.org/browse/JBAS-9570
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Components: Transaction Manager (JBossTM)
> Environment: Jboss: 3.2.5
> Jdk: 1.4
> Reporter: usman hassan
> Assignee: Stefano Maestri
>
> I have a issue in my jboss where my current transaction gets
> interrupted. I am getting the following error from my logs.
> 2015-03-10 07:13:15,911 FATAL [SDES.HubManager.DynamicTransactionDelegate] [01A713400A03140CD99F6EC4013F8919] finderException while stamping delivery Find failed: org.jboss.util.NestedSQLException: Interrupted while requesting permit! Waited 0 ms, invocation time: 1425957195897; - nested throwable: (javax.resource.ResourceException: Interrupted while requesting permit! Waited 0 ms, invocation time: 1425957195897
> In addition to above below connection factory not bound error is also frequent in the logs
> 2015-03-09 14:48:51,386 WARN [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] javax.naming.NameNotFoundException: XAConnectionFactory not bound
> Effect on Application:
> Even though the above errors are there but application seems to be working fine for some days but it suddenly starts misbehaving when the load is high.
> Any suggestion/hint to resolve the issue will be more then welcomed. Thanks in Advance.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (JBAS-9570) Envirnment:
by usman hassan (JIRA)
usman hassan created JBAS-9570:
----------------------------------
Summary: Envirnment:
Key: JBAS-9570
URL: https://issues.jboss.org/browse/JBAS-9570
Project: Application Server 3 4 5 and 6
Issue Type: Bug
Components: Transaction Manager (JBossTM)
Reporter: usman hassan
Assignee: Stefano Maestri
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months