[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)
9 years, 7 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)
9 years, 7 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)
9 years, 7 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)
9 years, 7 months
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1910:
-----------------------------------------------
Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1189839|https://bugzilla.redhat.com/show_bug.cgi?id=1189839] from ON_QA to ASSIGNED
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: SplitMergeFailFastTest.java, SplitMergeTest.java
>
>
> When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
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 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 3:22 AM:
-------------------------------------------------------------
{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.
> 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 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 3:18 AM:
-------------------------------------------------------------
{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.
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().
> 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 jeremy_lv lv (JIRA)
[ https://issues.jboss.org/browse/WFLY-4413?page=com.atlassian.jira.plugin.... ]
jeremy_lv lv commented on WFLY-4413:
------------------------------------
{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().
> 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